perm filename CLCLEA.5[COM,LSP] blob
sn#870941 filedate 1989-03-13 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00608 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00088 00002
C00089 00003 ∂11-Dec-88 1051 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
C00094 00004 ∂11-Dec-88 1549 CL-Cleanup-mailer Issue PACKAGE-CLUTTER (Version 5)
C00096 00005 ∂12-Dec-88 0929 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
C00100 00006 ∂12-Dec-88 0930 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
C00103 00007 ∂12-Dec-88 0929 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
C00106 00008 ∂12-Dec-88 0929 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE (Version 2)
C00109 00009 ∂12-Dec-88 0949 CL-Cleanup-mailer Issue: DEFSTRUCT-REDEFINITION (version 1)
C00113 00010 ∂12-Dec-88 1025 CL-Cleanup-mailer Re: discussion of Moon's comments re: ELIMINATE-FORCED-CONSING
C00115 00011 ∂12-Dec-88 1143 CL-Cleanup-mailer RE: Issue: HASH-TABLE-ACCESS (version 2)
C00117 00012 ∂12-Dec-88 1212 CL-Cleanup-mailer Re: Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY)
C00119 00013 ∂12-Dec-88 1444 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION (Version 4)
C00124 00014 ∂12-Dec-88 1448 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 5)
C00127 00015 ∂12-Dec-88 1527 CL-Cleanup-mailer Re: Issue: SYMBOL-MACROFLET (Version 1)
C00129 00016 ∂12-Dec-88 1546 CL-Cleanup-mailer REST-LIST-ALLOCATION (Version 3)
C00143 00017 ∂12-Dec-88 1748 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
C00147 00018 ∂12-Dec-88 1755 X3J13-mailer Issue: TAILP-NIL (Version 5)
C00149 00019 ∂12-Dec-88 2019 CL-Cleanup-mailer Issue: STREAM-INFO (Version 6)
C00151 00020 ∂13-Dec-88 0831 CL-Cleanup-mailer Issue: TAILP-NIL (Version 5)
C00154 00021 ∂13-Dec-88 0856 CL-Cleanup-mailer Issue: TAILP-NIL (Version 5)
C00157 00022 ∂13-Dec-88 1130 CL-Cleanup-mailer New issue: COMPLEX-ATAN-BRANCH-CUT
C00162 00023 ∂13-Dec-88 1131 CL-Cleanup-mailer New issue: IEEE-ATAN-BRANCH-CUT
C00170 00024 ∂13-Dec-88 1446 CL-Cleanup-mailer Issues: SETF-PLACES, SETF-FUNCTION-VERSUS-MACRO
C00175 00025 ∂13-Dec-88 1509 CL-Cleanup-mailer Issue: PACKAGE-DELETION (Version 5)
C00178 00026 ∂13-Dec-88 1606 CL-Cleanup-mailer Issue: TAILP-NIL (Version 5)
C00186 00027 ∂13-Dec-88 1645 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 9)
C00191 00028 ∂13-Dec-88 1800 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 5)
C00223 00029 ∂13-Dec-88 1816 CL-Cleanup-mailer Issue: REST-LIST-ALLOCATION (Version 3)
C00228 00030 ∂13-Dec-88 2111 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
C00243 00031 ∂13-Dec-88 2201 CL-Cleanup-mailer Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)
C00248 00032 ∂13-Dec-88 2207 CL-Cleanup-mailer Re: Issue ALIST-NIL
C00250 00033 ∂13-Dec-88 2215 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
C00253 00034 ∂13-Dec-88 2241 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
C00259 00035 ∂14-Dec-88 0007 CL-Cleanup-mailer Issue: TAILP-NIL (Version 5)
C00262 00036 ∂14-Dec-88 0019 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE (Version 2)
C00264 00037 ∂14-Dec-88 0143 CL-Cleanup-mailer Issue: DEFPACKAGE (Version 7)
C00267 00038 ∂14-Dec-88 0208 CL-Cleanup-mailer Please add me to the cl-cleanup mailing list
C00269 00039 ∂14-Dec-88 1037 CL-Cleanup-mailer Issue: TAILP-NIL (Version 5)
C00273 00040 ∂14-Dec-88 1157 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 6)
C00275 00041 ∂15-Dec-88 1315 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
C00278 00042 ∂15-Dec-88 1358 CL-Cleanup-mailer Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY)
C00283 00043 ∂15-Dec-88 1444 CL-Cleanup-mailer Issue: PACKAGE-DELETION (Version 5)
C00285 00044 ∂15-Dec-88 1515 CL-Cleanup-mailer Issue: PACKAGE-DELETION (Version 5)
C00288 00045 ∂15-Dec-88 2136 CL-Cleanup-mailer Issue: TAILP-NIL (Version 5)
C00291 00046 ∂15-Dec-88 2203 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 5)
C00294 00047 ∂16-Dec-88 0108 CL-Cleanup-mailer Really about the ontology of EQ {Issue: TAILP-NIL (Version 5)}
C00299 00048 ∂16-Dec-88 0838 CL-Cleanup-mailer EQ
C00302 00049 ∂16-Dec-88 1101 CL-Cleanup-mailer Really about the ontology of EQ {Issue: TAILP-NIL (Version 5)}
C00304 00050 ∂17-Dec-88 0118 CL-Cleanup-mailer EQ
C00309 00051 ∂17-Dec-88 1338 CL-Cleanup-mailer Re: EQ
C00312 00052 ∂20-Dec-88 1710 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 5)
C00317 00053 ∂22-Dec-88 1127 CL-Cleanup-mailer Issue: LISP-PACKAGE-NAME (Version 1)
C00330 00054 ∂22-Dec-88 1350 CL-Cleanup-mailer Re: Issue: LISP-PACKAGE-NAME (Version 1)
C00334 00055 ∂22-Dec-88 1545 CL-Cleanup-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C00345 00056 ∂22-Dec-88 1614 CL-Cleanup-mailer Re: Issue: LISP-PACKAGE-NAME (Version 1)
C00353 00057 ∂27-Dec-88 1209 CL-Cleanup-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C00358 00058 ∂27-Dec-88 1716 CL-Cleanup-mailer Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
C00371 00059 ∂27-Dec-88 1724 CL-Cleanup-mailer Issue: SETF-SUB-METHODS
C00373 00060 ∂28-Dec-88 1133 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
C00386 00061 ∂28-Dec-88 1259 CL-Cleanup-mailer Issue: PATHNAME-EXTENSIONS (Version 1)
C00396 00062 ∂29-Dec-88 0353 CL-Cleanup-mailer Issue: SETF-SUB-METHODS
C00399 00063 ∂29-Dec-88 1006 CL-Cleanup-mailer Issue: PATHNAME-EXTENSIONS (Version 1)
C00401 00064 ∂29-Dec-88 1031 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
C00409 00065 ∂29-Dec-88 1038 CL-Cleanup-mailer Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
C00411 00066 ∂29-Dec-88 1040 CL-Cleanup-mailer Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
C00414 00067 ∂29-Dec-88 1119 CL-Cleanup-mailer Issue: PATHNAME-EXTENSIONS (Version 1)
C00419 00068 ∂29-Dec-88 1132 CL-Cleanup-mailer Issue: PATHNAME-EXTENSIONS (Version 1)
C00422 00069 ∂29-Dec-88 1153 CL-Cleanup-mailer Issue: PATHNAME-EXTENSIONS (Version 1)
C00426 00070 ∂29-Dec-88 1157 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
C00439 00071 ∂29-Dec-88 1219 CL-Cleanup-mailer Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
C00441 00072 ∂29-Dec-88 1228 CL-Cleanup-mailer Issue: PATHNAME-EXTENSIONS (Version 1)
C00453 00073 ∂29-Dec-88 1308 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
C00462 00074 ∂29-Dec-88 1451 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
C00465 00075 ∂29-Dec-88 1834 CL-Cleanup-mailer Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C00467 00076 ∂30-Dec-88 0234 CL-Cleanup-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C00470 00077 ∂30-Dec-88 1425 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
C00476 00078 ∂30-Dec-88 1432 CL-Cleanup-mailer Issue SPECIAL-TYPE-SHADOWING (V1)
C00478 00079 ∂30-Dec-88 1446 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
C00488 00080 ∂30-Dec-88 1525 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE (Version 2)
C00493 00081 ∂30-Dec-88 1628 CL-Cleanup-mailer Issue GC-MESSAGES (Version 2)
C00496 00082 ∂30-Dec-88 1650 CL-Cleanup-mailer Issue GC-MESSAGES (Version 2)
C00502 00083 ∂31-Dec-88 1935 CL-Cleanup-mailer Issue SYNTACTIC-ENVIRONMENT-ACCESS
C00504 00084 ∂31-Dec-88 2001 CL-Cleanup-mailer Issue EXIT-EXTENT, v5
C00508 00085 ∂01-Jan-89 0259 CL-Cleanup-mailer *** HELP ***
C00510 00086 ∂01-Jan-89 0302 CL-Cleanup-mailer Issue FIXNUM-NON-PORTABLE, v4
C00513 00087 ∂01-Jan-89 2142 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
C00517 00088 ∂01-Jan-89 2359 CL-Cleanup-mailer Issue SYNTACTIC-ENVIRONMENT-ACCESS
C00520 00089 ∂02-Jan-89 1037 CL-Cleanup-mailer Issue: REST-LIST-ALLOCATION (Version 3)
C00527 00090 ∂02-Jan-89 1044 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
C00534 00091 ∂02-Jan-89 1045 CL-Cleanup-mailer *** HELP ***
C00536 00092 ∂02-Jan-89 1202 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 2)
C00551 00093 ∂02-Jan-89 1233 CL-Cleanup-mailer Issue: REST-LIST-ALLOCATION (Version 3)
C00560 00094 ∂02-Jan-89 1328 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 1)
C00570 00095 ∂02-Jan-89 1444 CL-Cleanup-mailer [Kim A. Barrett <IIM@ECLA.USC.EDU>: Ballot reply]
C00598 00096 ∂02-Jan-89 1455 CL-Cleanup-mailer re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2)
C00601 00097 ∂02-Jan-89 1517 CL-Cleanup-mailer re: Issue: EQUAL-STRUCTURE (Version 5)
C00605 00098 ∂02-Jan-89 1517 CL-Cleanup-mailer re: Issue: EXIT-EXTENT (Version 5)
C00607 00099 ∂02-Jan-89 1521 CL-Cleanup-mailer re: Issue: EXIT-EXTENT (Version 5)
C00609 00100 ∂02-Jan-89 1521 CL-Cleanup-mailer re: Issue: FIXNUM-NON-PORTABLE (Version 4)
C00612 00101 ∂02-Jan-89 1524 CL-Cleanup-mailer re: Issue: PACKAGE-CLUTTER:REDUCE (Version 6)
C00613 00102 ∂02-Jan-89 1525 CL-Cleanup-mailer re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
C00615 00103 ∂02-Jan-89 1524 CL-Cleanup-mailer re: Issue: HASH-TABLE-STABILITY (Version 1)
C00617 00104 ∂02-Jan-89 1528 CL-Cleanup-mailer re: Issue: REST-LIST-ALLOCATION (Version 3)
C00619 00105 ∂02-Jan-89 1529 CL-Cleanup-mailer re: Issue: STEP-ENVIRONMENT (Version 3)
C00621 00106 ∂02-Jan-89 1635 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
C00639 00107 ∂02-Jan-89 1737 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
C00651 00108 ∂02-Jan-89 1811 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
C00654 00109 ∂02-Jan-89 1820 CL-Cleanup-mailer Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
C00656 00110 ∂02-Jan-89 1821 CL-Cleanup-mailer Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
C00658 00111 ∂02-Jan-89 1836 CL-Cleanup-mailer Issues: SINGLE-FLOAT-NON-PORTABLE,
C00670 00112 ∂02-Jan-89 1852 CL-Cleanup-mailer Re: Issue: TAILP-NIL (Version 5)
C00673 00113 ∂02-Jan-89 1916 CL-Cleanup-mailer Re: Issue: REST-LIST-ALLOCATION (Version 3)
C00676 00114 ∂02-Jan-89 2102 CL-Cleanup-mailer Re: Issue: PATHNAME-PRINT-READ (Version 1)
C00678 00115 ∂02-Jan-89 2109 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL ?
C00680 00116 ∂02-Jan-89 2118 CL-Cleanup-mailer Re: issue COMPILE-ARGUMENT-PROBLEMS
C00684 00117 ∂02-Jan-89 2118 CL-Cleanup-mailer Re: issue COMPILE-ARGUMENT-PROBLEMS
C00686 00118 ∂02-Jan-89 2127 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 5)
C00688 00119 ∂02-Jan-89 2210 CL-Cleanup-mailer Re: issue COMPILE-ARGUMENT-PROBLEMS
C00692 00120 ∂02-Jan-89 2214 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
C00700 00121 ∂02-Jan-89 2225 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1)
C00702 00122 ∂02-Jan-89 2236 CL-Cleanup-mailer Re: Issue: DELETE-FILE-NONEXISTENT (Version 1)
C00704 00123 ∂02-Jan-89 2248 CL-Cleanup-mailer Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
C00706 00124 ∂03-Jan-89 0027 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
C00711 00125 ∂03-Jan-89 0542 CL-Cleanup-mailer Re: Issue: DYNAMIC-EXTENT (Version 2)
C00716 00126 ∂03-Jan-89 0758 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL ?
C00719 00127 ∂03-Jan-89 0800 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
C00721 00128 ∂03-Jan-89 0812 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
C00725 00129 ∂03-Jan-89 0834 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 2)
C00727 00130 ∂03-Jan-89 0902 CL-Cleanup-mailer Re: Issue: REST-LIST-ALLOCATION (Version 3)
C00730 00131 ∂03-Jan-89 0916 CL-Cleanup-mailer Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
C00736 00132 ∂03-Jan-89 0924 CL-Cleanup-mailer Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
C00741 00133 ∂03-Jan-89 0938 CL-Cleanup-mailer Re: Issue: REST-LIST-ALLOCATION (Version 3)
C00745 00134 ∂03-Jan-89 0946 CL-Cleanup-mailer Re: Issue GC-MESSAGES (Version 2)
C00748 00135 ∂03-Jan-89 0952 CL-Cleanup-mailer Re: Issue GC-MESSAGES (Version 2)
C00752 00136 ∂03-Jan-89 0955 CL-Cleanup-mailer Re: Issue COMPILER-DIAGNOSTICS, v7
C00754 00137 ∂03-Jan-89 1020 CL-Cleanup-mailer Re: Issue: PATHNAME-EXTENSIONS (Version 1)
C00757 00138 ∂03-Jan-89 1056 CL-Cleanup-mailer Re: Issue COMPILER-DIAGNOSTICS, v7
C00762 00139 ∂03-Jan-89 1056 CL-Cleanup-mailer Re: Issue GC-MESSAGES (Version 2)
C00771 00140 ∂03-Jan-89 1227 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
C00774 00141 ∂03-Jan-89 1507 CL-Cleanup-mailer ballot
C00787 00142 ∂03-Jan-89 1818 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
C00789 00143 ∂03-Jan-89 1819 CL-Cleanup-mailer meeting in Hawaii
C00790 00144 ∂03-Jan-89 1820 CL-Cleanup-mailer Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C00792 00145 ∂03-Jan-89 2230 CL-Cleanup-mailer Issue: REST-LIST-ALLOCATION (Version 3)
C00797 00146 ∂04-Jan-89 0103 CL-Cleanup-mailer Issue: HASH-TABLE-STABILITY (Version 1)
C00799 00147 ∂04-Jan-89 0140 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
C00803 00148 ∂04-Jan-89 0206 CL-Cleanup-mailer Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
C00806 00149 ∂04-Jan-89 0210 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL ?
C00808 00150 ∂04-Jan-89 0224 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
C00812 00151 ∂04-Jan-89 0311 CL-Cleanup-mailer Re: Issue FIXNUM-NON-PORTABLE, v4
C00814 00152 ∂04-Jan-89 0623 CL-Cleanup-mailer Re: Issue FIXNUM-NON-PORTABLE, v4
C00816 00153 ∂04-Jan-89 1116 CL-Cleanup-mailer Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
C00823 00154 ∂04-Jan-89 1137 CL-Cleanup-mailer Re: Issue FIXNUM-NON-PORTABLE, v4
C00826 00155 ∂04-Jan-89 1503 CL-Cleanup-mailer Issue PATHNAME-PRINT-READ, v1
C00828 00156 ∂04-Jan-89 1547 CL-Cleanup-mailer meeting in Hawaii
C00830 00157 ∂04-Jan-89 1549 CL-Cleanup-mailer Issue PATHNAME-PRINT-READ, v1
C00837 00158 ∂04-Jan-89 1633 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, v1
C00841 00159 ∂04-Jan-89 1641 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, v1
C00843 00160 ∂04-Jan-89 1900 CL-Cleanup-mailer meeting in Hawaii
C00845 00161 ∂05-Jan-89 1113 CL-Cleanup-mailer Symbolics response to mail ballot
C00874 00162 ∂05-Jan-89 1113 CL-Cleanup-mailer Issue PATHNAME-PRINT-READ, v1
C00876 00163 ∂05-Jan-89 1208 CL-Cleanup-mailer Issue PATHNAME-PRINT-READ, v1
C00878 00164 ∂05-Jan-89 1208 CL-Cleanup-mailer Symbolics response to mail ballot
C00907 00165 ∂05-Jan-89 1313 CL-Cleanup-mailer Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
C00920 00166 ∂05-Jan-89 1539 CL-Cleanup-mailer Issue: REST-LIST-ALLOCATION (Version 3)
C00922 00167 ∂05-Jan-89 1806 CL-Cleanup-mailer Ballot
C00932 00168 ∂05-Jan-89 2029 CL-Cleanup-mailer Issue PATHNAME-PRINT-READ, v1, and then some
C00937 00169 ∂06-Jan-89 0759 CL-Cleanup-mailer Re: Issue PATHNAME-PRINT-READ, v1, and then some
C00940 00170 ∂06-Jan-89 0919 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 1)
C00944 00171 ∂06-Jan-89 1006 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 1)
C00947 00172 ∂06-Jan-89 1115 CL-Cleanup-mailer Issue FUNCTION-COMPOSITION
C00949 00173 ∂06-Jan-89 1438 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 1)
C00956 00174 ∂06-Jan-89 1502 CL-Cleanup-mailer Re: Issue MACRO-FUNCTION-ENVIRONMENT, v1
C00969 00175 ∂06-Jan-89 1502 CL-Cleanup-mailer environment argument for SUBTYPEP
C00971 00176 ∂06-Jan-89 1503 CL-Cleanup-mailer Re: ballot
C00973 00177 ∂06-Jan-89 1504 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 6)
C00976 00178 ∂06-Jan-89 1506 CL-Cleanup-mailer Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
C00978 00179 ∂06-Jan-89 1503 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
C00981 00180 ∂06-Jan-89 1504 CL-Cleanup-mailer Issue APPLYHOOK-ENVIRONMENT (not submitted)
C00983 00181 ∂06-Jan-89 1504 CL-Cleanup-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)
C00987 00182 ∂06-Jan-89 1504 CL-Cleanup-mailer Meeting in Hawaii
C00988 00183 ∂06-Jan-89 1526 CL-Cleanup-mailer Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
C00990 00184 ∂06-Jan-89 1528 CL-Cleanup-mailer Re: Issue PATHNAME-PRINT-READ, v1
C00992 00185 ∂06-Jan-89 1557 CL-Cleanup-mailer Issue FUNCTION-COMPOSITION
C00994 00186 ∂06-Jan-89 1618 CL-Cleanup-mailer Re: Issue FUNCTION-COMPOSITION
C00996 00187 ∂06-Jan-89 2117 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
C00999 00188 ∂06-Jan-89 2125 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 1)
C01002 00189 ∂06-Jan-89 2127 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 1)
C01007 00190 ∂06-Jan-89 2246 CL-Cleanup-mailer Re: Ballot
C01009 00191 ∂06-Jan-89 2247 CL-Cleanup-mailer Issue: COMPILE-AND-LOAD-VERBOSITY????
C01010 00192 ∂06-Jan-89 2248 CL-Cleanup-mailer *DRAFT* issue status
C01055 00193 ∂06-Jan-89 2246 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
C01058 00194 ∂06-Jan-89 2246 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 5)
C01060 00195 ∂06-Jan-89 2247 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 1)
C01062 00196 ∂06-Jan-89 2247 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01065 00197 ∂06-Jan-89 2247 CL-Cleanup-mailer Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C01067 00198 ∂06-Jan-89 2247 CL-Cleanup-mailer Issue: APPLYHOOK-ENVIRONMENT (Version 1)
C01070 00199 ∂06-Jan-89 2247 CL-Cleanup-mailer Re: Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)
C01078 00200 ∂06-Jan-89 2258 CL-Cleanup-mailer Issue FUNCTION-COMPOSITION
C01080 00201 ∂06-Jan-89 2311 CL-Cleanup-mailer Ballots, please
C01082 00202 ∂06-Jan-89 2349 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (Version 7)
C01086 00203 ∂07-Jan-89 0007 CL-Cleanup-mailer Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE (Version 2)
C01090 00204 ∂07-Jan-89 0100 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 1)
C01092 00205 ∂07-Jan-89 0927 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
C01095 00206 ∂07-Jan-89 2109 CL-Cleanup-mailer votes at Hawaii
C01096 00207 ∂07-Jan-89 2109 CL-Cleanup-mailer [alarson@src.honeywell.com (Aaron Larson): Ballots, please]
C01117 00208 ∂07-Jan-89 2153 CL-Cleanup-mailer Issue PATHNAME-PRINT-READ, v1
C01123 00209 ∂07-Jan-89 2212 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
C01125 00210 ∂07-Jan-89 2223 CL-Cleanup-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C01127 00211 ∂07-Jan-89 2235 CL-Cleanup-mailer Issue: DEFSTRUCT-REDEFINITION (Version 2)
C01136 00212 ∂08-Jan-89 0035 CL-Cleanup-mailer Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C01140 00213 ∂08-Jan-89 0113 CL-Cleanup-mailer Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)
C01148 00214 ∂08-Jan-89 0145 CL-Cleanup-mailer Re: Issue: DYNAMIC-EXTENT (Version 2)
C01150 00215 ∂08-Jan-89 0831 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 2)
C01157 00216 ∂08-Jan-89 1327 CL-Editorial-mailer conformance & extensions issues
C01165 00217 ∂08-Jan-89 1341 CL-Cleanup-mailer Issue: ELIMINATE-FORCED-CONSING (Version 3)
C01168 00218 ∂08-Jan-89 1400 CL-Cleanup-mailer Re: Ballot
C01170 00219 ∂08-Jan-89 1405 CL-Cleanup-mailer Re: Ballot
C01172 00220 ∂08-Jan-89 1416 CL-Cleanup-mailer Re: Issue: LISP-SYMBOL-REDEFINITION (Version 5)
C01175 00221 ∂08-Jan-89 1735 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
C01178 00222 ∂08-Jan-89 1833 CL-Cleanup-mailer Issue: APPLYHOOK-ENVIRONMENT (Version 1)
C01180 00223 ∂08-Jan-89 2251 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 6)
C01205 00224 ∂08-Jan-89 2334 CL-Cleanup-mailer Re: Issue FIXNUM-NON-PORTABLE, v4
C01208 00225 ∂08-Jan-89 2357 CL-Cleanup-mailer Re: Issue: FORMAT-ROUNDING (Version 1)
C01210 00226 ∂08-Jan-89 2359 CL-Cleanup-mailer Re: Issue: FUNCTION-COERCE-TIME (Version 2)
C01212 00227 ∂09-Jan-89 0013 CL-Cleanup-mailer Re: Issue GC-MESSAGES (Version 2)
C01215 00228 ∂09-Jan-89 0644 CL-Cleanup-mailer Re: Issue FUNCTION-COMPOSITION
C01216 00229 ∂09-Jan-89 0644 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 1)
C01218 00230 ∂09-Jan-89 0933 CL-Cleanup-mailer Meeting in Hawaii
C01220 00231 ∂09-Jan-89 1020 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 1)
C01221 00232 ∂09-Jan-89 1059 CL-Cleanup-mailer Issues: REQUIRE-PATHNAME-DEFAULTS and LOAD-TRUENAME
C01238 00233 ∂09-Jan-89 1119 CL-Cleanup-mailer Re: Issue: EXIT-EXTENT (Version 6)
C01241 00234 ∂09-Jan-89 1125 CL-Cleanup-mailer re: Issue: EQUAL-STRUCTURE (Version 5)
C01248 00235 ∂09-Jan-89 1142 CL-Cleanup-mailer Re: Ballots, please
C01249 00236 ∂09-Jan-89 1318 CL-Cleanup-mailer Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
C01251 00237 ∂09-Jan-89 1320 CL-Cleanup-mailer Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
C01254 00238 ∂09-Jan-89 1553 CL-Cleanup-mailer Re: Ballots, please
C01256 00239 ∂09-Jan-89 1609 CL-Cleanup-mailer Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
C01260 00240 ∂09-Jan-89 1722 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 1)
C01262 00241 ∂09-Jan-89 1728 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 2)
C01264 00242 ∂09-Jan-89 1822 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 2)
C01281 00243 ∂09-Jan-89 1913 CL-Cleanup-mailer Re: Issue: OUTPUT-STREAM-P-EXAMPLE
C01283 00244 ∂09-Jan-89 1914 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 5)
C01285 00245 ∂09-Jan-89 1913 CL-Cleanup-mailer re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
C01288 00246 ∂09-Jan-89 1913 CL-Cleanup-mailer Re: Issue: REST-LIST-ALLOCATION (Version 3)
C01290 00247 ∂09-Jan-89 1943 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 5)
C01293 00248 ∂09-Jan-89 1952 CL-Cleanup-mailer Re: Ballots, please
C01294 00249 ∂09-Jan-89 1956 CL-Cleanup-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C01300 00250 ∂09-Jan-89 2142 CL-Cleanup-mailer Issue: FORMAT-ROUNDING (Version 1)
C01302 00251 ∂09-Jan-89 2203 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 5)
C01304 00252 ∂09-Jan-89 2230 CL-Cleanup-mailer ballot
C01321 00253 ∂09-Jan-89 2233 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 5)
C01323 00254 ∂09-Jan-89 2238 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
C01325 00255 ∂09-Jan-89 2335 CL-Cleanup-mailer [chapman%aitg.DEC@decwrl.dec.com: vote]
C01336 00256 ∂09-Jan-89 2341 CL-Cleanup-mailer Re: revised ISO discussion, revised DRAFT Gegenda and Subcommittee
C01338 00257 ∂10-Jan-89 0022 CL-Cleanup-mailer Issue: STREAM-ACCESS (Version 2)
C01340 00258 ∂10-Jan-89 0024 CL-Cleanup-mailer Issue: STREAM-INFO (Version 6)
C01344 00259 ∂10-Jan-89 0039 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 1)
C01346 00260 ∂10-Jan-89 0039 CL-Cleanup-mailer Revised draft issue status
C01399 00261 ∂10-Jan-89 0149 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 5)
C01402 00262 ∂10-Jan-89 0413 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01405 00263 ∂10-Jan-89 0624 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 2)
C01413 00264 ∂10-Jan-89 0733 CL-Cleanup-mailer Issue: STREAM-INFO (Version 6)
C01418 00265 ∂10-Jan-89 0906 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
C01421 00266 ∂10-Jan-89 0948 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 2)
C01423 00267 ∂10-Jan-89 1019 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
C01427 00268 ∂10-Jan-89 1042 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 2)
C01445 00269 ∂10-Jan-89 1042 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 5)
C01448 00270 ∂10-Jan-89 1050 CL-Cleanup-mailer Issue: STREAM-INFO (Version 6)
C01452 00271 ∂10-Jan-89 1101 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 2)
C01456 00272 ∂10-Jan-89 1429 CL-Cleanup-mailer Issue: STREAM-INFO (Version 6)
C01463 00273 ∂10-Jan-89 1441 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
C01466 00274 ∂10-Jan-89 1443 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01469 00275 ∂10-Jan-89 1458 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01471 00276 ∂10-Jan-89 1506 CL-Cleanup-mailer revised ISO discussion, revised DRAFT Gegenda and Subcommittee
C01473 00277 ∂10-Jan-89 1508 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
C01475 00278 ∂10-Jan-89 1527 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 6)
C01477 00279 ∂10-Jan-89 1536 CL-Cleanup-mailer Re: New proposed issue APPEND-ATOM
C01479 00280 ∂10-Jan-89 1551 CL-Cleanup-mailer New proposed issue APPEND-ATOM
C01488 00281 ∂10-Jan-89 1551 CL-Cleanup-mailer Re: New proposed issue APPEND-ATOM
C01491 00282 ∂10-Jan-89 1552 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
C01499 00283 ∂10-Jan-89 1556 CL-Cleanup-mailer Possible issue: GCD-NO-ARGUMENTS
C01503 00284 ∂10-Jan-89 1610 CL-Cleanup-mailer cleanup ballot
C01514 00285 ∂10-Jan-89 1610 CL-Cleanup-mailer cleanup ballot
C01525 00286 ∂10-Jan-89 2248 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
C01528 00287 ∂11-Jan-89 0004 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 5)
C01533 00288 ∂11-Jan-89 0126 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01536 00289 ∂11-Jan-89 1217 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
C01539 00290 ∂11-Jan-89 1429 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 6)
C01549 00291 ∂11-Jan-89 1430 CL-Cleanup-mailer Issue: APPLYHOOK-ENVIRONMENT (Version 2)
C01552 00292 ∂11-Jan-89 1431 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
C01554 00293 ∂11-Jan-89 1430 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4)
C01571 00294 ∂11-Jan-89 1431 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
C01581 00295 ∂11-Jan-89 1458 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
C01584 00296 ∂11-Jan-89 1513 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01588 00297 ∂11-Jan-89 1514 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 5)
C01593 00298 ∂11-Jan-89 1515 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 5)
C01595 00299 ∂11-Jan-89 1516 CL-Cleanup-mailer Re: New proposed issue APPEND-ATOM
C01597 00300 ∂11-Jan-89 1517 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 5)
C01599 00301 ∂11-Jan-89 1522 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
C01601 00302 ∂11-Jan-89 1514 CL-Cleanup-mailer Ballot response
C01628 00303 ∂11-Jan-89 1522 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 3)
C01647 00304 ∂11-Jan-89 1522 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 2)
C01666 00305 ∂11-Jan-89 1534 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 6)
C01668 00306 ∂11-Jan-89 1558 CL-Cleanup-mailer Re: Issue: EXIT-EXTENT (Version 6)
C01669 00307 ∂11-Jan-89 1601 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 5)
C01671 00308 ∂11-Jan-89 1614 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
C01674 00309 ∂11-Jan-89 1652 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 2)
C01676 00310 ∂11-Jan-89 1722 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 1)
C01679 00311 ∂11-Jan-89 1750 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01682 00312 ∂11-Jan-89 1812 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01687 00313 ∂11-Jan-89 1821 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (Version 7)
C01692 00314 ∂11-Jan-89 1928 CL-Cleanup-mailer Issue: DEFPACKAGE (Version 7)
C01698 00315 ∂11-Jan-89 1957 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
C01700 00316 ∂11-Jan-89 1957 CL-Cleanup-mailer Possible issue: GCD-NO-ARGUMENTS
C01702 00317 ∂11-Jan-89 2007 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 2)
C01705 00318 ∂11-Jan-89 2016 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01708 00319 ∂11-Jan-89 2138 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01712 00320 ∂11-Jan-89 2148 CL-Cleanup-mailer New versions vs amendments
C01714 00321 ∂11-Jan-89 2222 CL-Cleanup-mailer Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
C01716 00322 ∂12-Jan-89 0033 CL-Cleanup-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
C01718 00323 ∂12-Jan-89 0037 CL-Cleanup-mailer Issue: PROCLAIM-SPECIAL (Version 9)
C01722 00324 ∂12-Jan-89 0048 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 5)
C01724 00325 ∂12-Jan-89 0309 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
C01727 00326 ∂12-Jan-89 0420 CL-Cleanup-mailer Issue: DEFPACKAGE (Version 7)
C01730 00327 ∂12-Jan-89 0520 CL-Cleanup-mailer ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
C01746 00328 ∂12-Jan-89 0924 CL-Cleanup-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
C01753 00329 ∂12-Jan-89 0937 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 5)
C01755 00330 ∂12-Jan-89 0953 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 6)
C01758 00331 ∂12-Jan-89 1038 CL-Cleanup-mailer Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
C01762 00332 ∂12-Jan-89 1054 CL-Cleanup-mailer Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
C01764 00333 ∂12-Jan-89 1106 CL-Cleanup-mailer Re: Issue: PROCLAIM-SPECIAL (Version 9)
C01766 00334 ∂12-Jan-89 1106 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 10)
C01784 00335 ∂12-Jan-89 1124 CL-Cleanup-mailer Issue: NTH-VALUE (Version 4)
C01789 00336 ∂12-Jan-89 1143 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 5)
C01796 00337 ∂12-Jan-89 1505 CL-Cleanup-mailer Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
C01798 00338 ∂12-Jan-89 1518 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 5)
C01800 00339 ∂12-Jan-89 1524 CL-Cleanup-mailer Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
C01802 00340 ∂12-Jan-89 1536 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME , Version 4
C01808 00341 ∂12-Jan-89 1745 CL-Cleanup-mailer Issue Status
C01870 00342 ∂12-Jan-89 2036 CL-Cleanup-mailer Issue: APPEND-FIASCO (Version 2)
C01888 00343 ∂12-Jan-89 2112 CL-Cleanup-mailer Issue: REMF-MULTIPLE (Version 2)
C01890 00344 ∂12-Jan-89 2157 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01893 00345 ∂12-Jan-89 2333 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01896 00346 ∂13-Jan-89 0751 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 2)
C01903 00347 ∂13-Jan-89 0858 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 2)
C01909 00348 ∂13-Jan-89 0935 CL-Cleanup-mailer Re: Issue: NTH-VALUE (Version 4)
C01913 00349 ∂13-Jan-89 0958 CL-Cleanup-mailer Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE , Version 3
C01918 00350 ∂13-Jan-89 1022 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01920 00351 ∂13-Jan-89 1022 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01922 00352 ∂13-Jan-89 1039 CL-Cleanup-mailer Re: Issue: REMF-MULTIPLE (Version 2)
C01924 00353 ∂13-Jan-89 1039 CL-Cleanup-mailer Re: Issue: APPEND-FIASCO (Version 2)
C01926 00354 ∂13-Jan-89 1049 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 3)
C01932 00355 ∂13-Jan-89 1052 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 3)
C01945 00356 ∂13-Jan-89 1053 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01949 00357 ∂13-Jan-89 1109 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 3)
C01957 00358 ∂13-Jan-89 1126 CL-Cleanup-mailer Re: Issue: NTH-VALUE (Version 4)
C01960 00359 ∂13-Jan-89 1129 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME , Version 4
C01963 00360 ∂13-Jan-89 1320 CL-Cleanup-mailer Re: Issue: NTH-VALUE (Version 4)
C01966 00361 ∂13-Jan-89 1448 CL-Cleanup-mailer Ballot
C01979 00362 ∂13-Jan-89 1454 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 2)
C01999 00363 ∂13-Jan-89 1602 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 2)
C02002 00364 ∂13-Jan-89 1631 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 6)
C02007 00365 ∂13-Jan-89 1903 CL-Editorial-mailer Code as Spec: {Issue: THE-AMBIGUITY (Version 2)}
C02012 00366 ∂13-Jan-89 1913 CL-Cleanup-mailer Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
C02014 00367 ∂13-Jan-89 2000 CL-Cleanup-mailer Issue: CLOSE-CONSTRUCTED-STREAM (Version 2)
C02016 00368 ∂13-Jan-89 2058 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 2)
C02024 00369 ∂14-Jan-89 0336 CL-Cleanup-mailer Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE, v3
C02026 00370 ∂15-Jan-89 0547 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C02029 00371 ∂15-Jan-89 0557 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 3)
C02033 00372 ∂15-Jan-89 0617 CL-Cleanup-mailer Issue: NTH-VALUE (Version 4)
C02036 00373 ∂18-Jan-89 1123 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
C02051 00374 ∂20-Jan-89 1453 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
C02055 00375 ∂20-Jan-89 1501 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 5
C02069 00376 ∂23-Jan-89 0238 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 5
C02071 00377 ∂23-Jan-89 0820 CL-Cleanup-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C02074 00378 ∂23-Jan-89 1032 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
C02080 00379 ∂23-Jan-89 1532 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
C02082 00380 ∂23-Jan-89 1640 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Backquote Documentation
C02086 00381 ∂23-Jan-89 2027 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
C02090 00382 ∂23-Jan-89 2148 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
C02094 00383 ∂24-Jan-89 0327 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 5
C02100 00384 ∂24-Jan-89 1043 CL-Cleanup-mailer Re: issue IN-PACKAGE-FUNCTIONALITY, version 5
C02107 00385 ∂24-Jan-89 1433 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 1)
C02116 00386 ∂24-Jan-89 1527 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 1)
C02119 00387 ∂24-Jan-89 1722 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 1)
C02122 00388 ∂24-Jan-89 1917 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 1)
C02124 00389 ∂25-Jan-89 0251 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 1)
C02127 00390 ∂25-Jan-89 0523 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 5
C02131 00391 ∂25-Jan-89 0840 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
C02146 00392 ∂25-Jan-89 1018 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 1)
C02148 00393 ∂25-Jan-89 1111 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 1)
C02151 00394 ∂25-Jan-89 1111 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 1)
C02153 00395 ∂25-Jan-89 1604 CL-Cleanup-mailer Issue status-- not 'till next week
C02155 00396 ∂25-Jan-89 1711 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
C02159 00397 ∂26-Jan-89 1215 CL-Cleanup-mailer Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION (Version 1)
C02171 00398 ∂27-Jan-89 0326 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
C02174 00399 ∂27-Jan-89 1755 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
C02186 00400 ∂27-Jan-89 1803 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
C02189 00401 ∂27-Jan-89 1805 CL-Cleanup-mailer Issue: LISP-PACKAGE-NAME, (Version 1)
C02192 00402 ∂27-Jan-89 1824 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
C02194 00403 ∂27-Jan-89 1844 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 5
C02200 00404 ∂27-Jan-89 1950 CL-Cleanup-mailer Issue: FUNCTION-NAME (Version 1)
C02225 00405 ∂28-Jan-89 1011 CL-Cleanup-mailer Re: issue IN-PACKAGE-FUNCTIONALITY, version 5
C02230 00406 ∂29-Jan-89 1325 Common-Lisp-Object-System-mailer Re: Issue: FUNCTION-NAME (Version 1)
C02233 00407 ∂29-Jan-89 1428 CL-Cleanup-mailer Re: issue IN-PACKAGE-FUNCTIONALITY, version 5
C02242 00408 ∂30-Jan-89 0653 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST (Version 1)
C02252 00409 ∂30-Jan-89 0704 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
C02257 00410 ∂30-Jan-89 0720 CL-Cleanup-mailer Issue: FUNCTION-NAME (Version 1)
C02259 00411 ∂30-Jan-89 0903 CL-Cleanup-mailer Issue: LISP-PACKAGE-NAME, (Version 1)
C02269 00412 ∂30-Jan-89 0910 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 5
C02272 00413 ∂30-Jan-89 0915 CL-Cleanup-mailer Re: issue IN-PACKAGE-FUNCTIONALITY, version 5
C02274 00414 ∂30-Jan-89 0917 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
C02276 00415 ∂30-Jan-89 1003 Common-Lisp-Object-System-mailer Issue: FUNCTION-NAME (Version 1)
C02278 00416 ∂30-Jan-89 1458 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C02281 00417 ∂30-Jan-89 1826 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 6
C02295 00418 ∂31-Jan-89 0233 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
C02300 00419 ∂01-Feb-89 1140 CL-Cleanup-mailer Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
C02308 00420 ∂01-Feb-89 1206 CL-Cleanup-mailer Re: Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
C02310 00421 ∂01-Feb-89 1208 CL-Cleanup-mailer Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
C02312 00422 ∂01-Feb-89 1224 CL-Cleanup-mailer Re: Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
C02316 00423 ∂01-Feb-89 2123 CL-Cleanup-mailer New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN
C02330 00424 ∂02-Feb-89 0532 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
C02335 00425 ∂02-Feb-89 0807 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
C02341 00426 ∂02-Feb-89 1239 CL-Cleanup-mailer Issue: FUNCTION-NAME (Version 1)
C02353 00427 ∂03-Feb-89 0820 CL-Compiler-mailer Re: Issue: FUNCTION-NAME (Version 1)
C02357 00428 ∂03-Feb-89 1513 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
C02363 00429 ∂03-Feb-89 1537 CL-Cleanup-mailer New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN
C02365 00430 ∂03-Feb-89 1542 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST (Version 1)
C02368 00431 ∂03-Feb-89 1557 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST (Version 1)
C02370 00432 ∂03-Feb-89 1602 CL-Cleanup-mailer Re: New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN
C02372 00433 ∂03-Feb-89 2211 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 5)
C02381 00434 ∂03-Feb-89 2218 CL-Cleanup-mailer Re: Issue: APPEND-DOTTED (Version 5)
C02383 00435 ∂03-Feb-89 2232 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 3)
C02416 00436 ∂03-Feb-89 2243 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 6)
C02426 00437 ∂03-Feb-89 2257 CL-Cleanup-mailer Re: Issue: CLOSED-STREAM-OPERATIONS (Version 6)
C02428 00438 ∂05-Feb-89 1111 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 3)
C02430 00439 ∂05-Feb-89 1519 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
C02434 00440 ∂05-Feb-89 1841 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
C02438 00441 ∂06-Feb-89 0841 CL-Cleanup-mailer New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN
C02441 00442 ∂06-Feb-89 0845 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
C02444 00443 ∂06-Feb-89 0851 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 6)
C02446 00444 ∂06-Feb-89 0902 CL-Cleanup-mailer Re: Issue: CLOSED-STREAM-OPERATIONS (Version 6)
C02449 00445 ∂06-Feb-89 0937 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
C02452 00446 ∂06-Feb-89 1017 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 6)
C02456 00447 ∂06-Feb-89 1150 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 2)
C02459 00448 ∂06-Feb-89 1213 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 2)
C02464 00449 ∂06-Feb-89 1251 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
C02467 00450 ∂06-Feb-89 1302 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
C02473 00451 ∂06-Feb-89 1316 CL-Cleanup-mailer issue SYMBOL-MACROLET-SEMANTICS
C02475 00452 ∂06-Feb-89 1307 Common-Lisp-Object-System-mailer issue SYMBOL-MACROLET-SEMANTICS
C02477 00453 ∂06-Feb-89 1354 CL-Cleanup-mailer Issue: IGNORE-VARIABLE (Version 1)
C02487 00454 ∂06-Feb-89 1419 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 2)
C02492 00455 ∂06-Feb-89 1638 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 2)
C02498 00456 ∂07-Feb-89 0819 CL-Windows-mailer I/O generic functions
C02512 00457 ∂07-Feb-89 1016 Common-Lisp-Object-System-mailer Re: I/O generic functions
C02514 00458 ∂07-Feb-89 1033 Common-Lisp-Object-System-mailer Re: I/O generic functions
C02518 00459 ∂07-Feb-89 1241 CL-Cleanup-mailer New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN, or Hokey-Pokey-ADJUST-ARRAY
C02533 00460 ∂07-Feb-89 1248 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
C02536 00461 ∂07-Feb-89 1252 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
C02538 00462 ∂07-Feb-89 1302 CL-Cleanup-mailer Issue: SUBTYPEP-EMPTY-NIL (Version 1)
C02543 00463 ∂07-Feb-89 1325 CL-Cleanup-mailer Issue: DEFSTRUCT-REDEFINITION (Version 3)
C02552 00464 ∂07-Feb-89 2005 CL-Cleanup-mailer I/O generic functions
C02556 00465 ∂07-Feb-89 2252 CL-Cleanup-mailer Issue: SUBTYPEP-EMPTY-NIL (Version 1)
C02558 00466 ∂08-Feb-89 0639 CL-Cleanup-mailer Issue: SUBTYPEP-EMPTY-NIL (Version 1)
C02562 00467 ∂08-Feb-89 0907 CL-Cleanup-mailer Re: Issue: IGNORE-VARIABLE (Version 1)
C02565 00468 ∂08-Feb-89 0921 CL-Cleanup-mailer Re: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
C02567 00469 ∂08-Feb-89 1010 CL-Cleanup-mailer Re: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
C02570 00470 ∂08-Feb-89 1107 CL-Cleanup-mailer Re: Issue: IGNORE-VARIABLE (Version 1)
C02577 00471 ∂08-Feb-89 1112 CL-Cleanup-mailer Issue: SUBTYPEP-EMPTY-NIL (Version 1)
C02579 00472 ∂08-Feb-89 1230 CL-Cleanup-mailer Issue: SUBTYPEP-EMPTY-NIL (Version 1)
C02583 00473 ∂08-Feb-89 1251 CL-Cleanup-mailer Re: Issue: IGNORE-VARIABLE (Version 1)
C02587 00474 ∂08-Feb-89 1428 CL-Cleanup-mailer Re: Issue: IGNORE-VARIABLE (Version 1)
C02592 00475 ∂08-Feb-89 1704 CL-Cleanup-mailer Re: I/O generic functions
C02598 00476 ∂08-Feb-89 2017 CL-Cleanup-mailer Issue: SUBTYPEP-EMPTY-NIL (Version 1)
C02601 00477 ∂09-Feb-89 0656 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 3)
C02604 00478 ∂10-Feb-89 1325 CL-Cleanup-mailer re: PATHNAME-PRINT-READ, v1
C02608 00479 ∂10-Feb-89 2353 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION (Version 5)
C02613 00480 ∂11-Feb-89 0023 CL-Cleanup-mailer Issue: FUNCTION-DEFINITION (Version 3)
C02622 00481 ∂13-Feb-89 1250 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
C02627 00482 ∂14-Feb-89 1213 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
C02633 00483 ∂14-Feb-89 1328 CL-Cleanup-mailer Re: Issue: GENSYM-NAME-STICKINESS (Version 1)
C02636 00484 ∂14-Feb-89 1615 CL-Cleanup-mailer Re: Issue: CLOS-CONDITIONS (Version 3)
C02638 00485 ∂14-Feb-89 1615 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C02655 00486 ∂14-Feb-89 1636 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 7)
C02666 00487 ∂14-Feb-89 1658 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE (Version 2)
C02668 00488 ∂15-Feb-89 0646 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C02673 00489 ∂15-Feb-89 0706 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 7)
C02678 00490 ∂15-Feb-89 0737 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE (Version 2)
C02681 00491 ∂15-Feb-89 0817 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C02683 00492 ∂15-Feb-89 0835 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C02685 00493 ∂15-Feb-89 1000 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C02689 00494 ∂15-Feb-89 1124 CL-Cleanup-mailer [Moon@STONY-BROOK.SCRC.Symbolics.COM: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)]
C02705 00495 ∂15-Feb-89 1126 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C02708 00496 ∂15-Feb-89 1206 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
C02714 00497 ∂15-Feb-89 1244 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 1)
C02727 00498 ∂15-Feb-89 1331 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 1)
C02740 00499 ∂15-Feb-89 1435 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C02744 00500 ∂15-Feb-89 1509 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C02750 00501 ∂16-Feb-89 0758 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C02757 00502 ∂16-Feb-89 0857 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C02767 00503 ∂16-Feb-89 1104 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C02781 00504 ∂16-Feb-89 1215 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C02788 00505 ∂16-Feb-89 1241 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C02791 00506 ∂17-Feb-89 0004 CL-Cleanup-mailer Cleanup Issue Status
C02837 00507 ∂17-Feb-89 1031 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C02844 00508 ∂17-Feb-89 1049 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C02848 00509 ∂20-Feb-89 0944 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C02852 00510 ∂21-Feb-89 1501 CL-Cleanup-mailer Issue IGNORE-VARIABLE, v1
C02854 00511 ∂21-Feb-89 1501 Common-Lisp-Object-System-mailer Issue CONSTANT-COMPILABLE-TYPES
C02862 00512 ∂22-Feb-89 1037 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C02866 00513 ∂22-Feb-89 1117 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C02870 00514 ∂23-Feb-89 1412 CL-Cleanup-mailer Potential issue: MACRO-SPECIAL-FORMS
C02876 00515 ∂23-Feb-89 1446 CL-Compiler-mailer Potential issue: MACRO-SPECIAL-FORMS
C02882 00516 ∂23-Feb-89 1502 CL-Cleanup-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
C02886 00517 ∂23-Feb-89 1525 CL-Compiler-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
C02891 00518 ∂24-Feb-89 0157 Common-Lisp-Object-System-mailer Issue CONSTANT-COMPILABLE-TYPES
C02895 00519 ∂24-Feb-89 1446 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE
C02952 00520 ∂27-Feb-89 0938 CL-Cleanup-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
C02959 00521 ∂27-Feb-89 1337 CL-Cleanup-mailer [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
C02963 00522 ∂27-Feb-89 1433 CL-Cleanup-mailer Re: PRETTY-PRINT-INTERFACE
C02967 00523 ∂27-Feb-89 1506 CL-Cleanup-mailer [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
C02969 00524 ∂27-Feb-89 1639 CL-Cleanup-mailer Issue: EXPT-ZERO-ZERO (Version 1)
C02975 00525 ∂27-Feb-89 1658 CL-Cleanup-mailer Re: Issue: EXPT-ZERO-ZERO (Version 1)
C02978 00526 ∂28-Feb-89 0240 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C02986 00527 ∂28-Feb-89 0949 CL-Cleanup-mailer Issue: EXPT-ZERO-ZERO (Version 1)
C02989 00528 ∂28-Feb-89 1148 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C03002 00529 ∂28-Feb-89 1402 CL-Cleanup-mailer Issue EQUALP-GENERIC
C03016 00530 ∂28-Feb-89 1508 CL-Cleanup-mailer Issue EQUALP-GENERIC
C03020 00531 ∂28-Feb-89 1758 CL-Cleanup-mailer Issue PRETTY-PRINT-INTERFACE
C03022 00532 ∂01-Mar-89 2009 CL-Cleanup-mailer Re: Issue EQUALP-GENERIC
C03026 00533 ∂01-Mar-89 2029 CL-Cleanup-mailer Issue EQUAL-STRUCTURE
C03030 00534 ∂01-Mar-89 2055 CL-Cleanup-mailer Issue EQUAL-STRUCTURE
C03033 00535 ∂04-Mar-89 1123 CL-Cleanup-mailer MERGE-PATHNAMES-DIRECTORY:EXTEND
C03045 00536 ∂04-Mar-89 1740 CL-Cleanup-mailer Issue EQUALP-GENERIC
C03048 00537 ∂04-Mar-89 1741 CL-Cleanup-mailer Issue EQUAL-STRUCTURE
C03051 00538 ∂06-Mar-89 1007 CL-Cleanup-mailer Re: Issue EQUAL-STRUCTURE
C03055 00539 ∂06-Mar-89 1445 CL-Cleanup-mailer Issue: OPTIMIZE-SAFETY (Version 1)
C03061 00540 ∂06-Mar-89 1717 CL-Cleanup-mailer [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
C03063 00541 ∂06-Mar-89 1831 CL-Cleanup-mailer Re: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
C03068 00542 ∂06-Mar-89 1911 CL-Cleanup-mailer Re: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
C03072 00543 ∂06-Mar-89 1921 CL-Cleanup-mailer Re: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
C03076 00544 ∂06-Mar-89 2031 CL-Cleanup-mailer Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER (Version 1)
C03108 00545 ∂06-Mar-89 2053 CL-Cleanup-mailer Issue: FORMAT-PLURALS [was "pluralization: two proposals"]
C03110 00546 ∂07-Mar-89 1047 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C03116 00547 ∂07-Mar-89 1054 CL-Cleanup-mailer [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
C03120 00548 ∂07-Mar-89 1135 CL-Cleanup-mailer [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
C03124 00549 ∂07-Mar-89 1443 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE (Version 3)
C03135 00550 ∂07-Mar-89 1504 CL-Cleanup-mailer MERGE-PATHNAMES-DIRECTORY:EXTEND
C03137 00551 ∂07-Mar-89 1637 CL-Cleanup-mailer Issue: OPTIMIZE-SAFETY (Version 1)
C03145 00552 ∂07-Mar-89 1643 CL-Cleanup-mailer Issue: BREAK-ON-WARNINGS-OBSOLETE
C03149 00553 ∂07-Mar-89 1722 CL-Cleanup-mailer Issue EQUALP-GENERIC
C03166 00554 ∂07-Mar-89 1825 CL-Compiler-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
C03171 00555 ∂07-Mar-89 2346 CL-Cleanup-mailer MERGE-PATHNAMES-DIRECTORY:EXTEND
C03174 00556 ∂08-Mar-89 0524 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME
C03177 00557 ∂08-Mar-89 0806 CL-Cleanup-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
C03179 00558 ∂08-Mar-89 0820 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME
C03181 00559 ∂08-Mar-89 0930 CL-Cleanup-mailer Issue: MERGE-PATHNAMES-DIRECTORY
C03183 00560 ∂08-Mar-89 0939 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME
C03185 00561 ∂08-Mar-89 0948 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME
C03188 00562 ∂08-Mar-89 0951 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME
C03190 00563 ∂08-Mar-89 0952 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME
C03193 00564 ∂08-Mar-89 1117 CL-Cleanup-mailer Issue: PLUS-ABNORMAL
C03199 00565 ∂08-Mar-89 1437 CL-Cleanup-mailer case sensitive readers
C03205 00566 ∂08-Mar-89 1628 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME
C03207 00567 ∂09-Mar-89 1109 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 3)
C03209 00568 ∂09-Mar-89 1120 CL-Cleanup-mailer Re: case sensitive readers
C03213 00569 ∂09-Mar-89 1128 CL-Cleanup-mailer Re: Issue: CLOS-CONDITIONS (Version 3)
C03217 00570 ∂09-Mar-89 1128 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
C03225 00571 ∂09-Mar-89 1135 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE (Version 3)
C03227 00572 ∂09-Mar-89 1228 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
C03234 00573 ∂09-Mar-89 1313 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
C03236 00574 ∂09-Mar-89 1325 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 2)
C03240 00575 ∂09-Mar-89 1329 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 3)
C03263 00576 ∂09-Mar-89 1334 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 6
C03265 00577 ∂09-Mar-89 1522 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
C03269 00578 ∂09-Mar-89 1527 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 3)
C03273 00579 ∂09-Mar-89 1541 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 6
C03275 00580 ∂09-Mar-89 1539 CL-Compiler-mailer Issue: LOCALLY-TOP-LEVEL (Version 1)
C03283 00581 ∂09-Mar-89 1635 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C03286 00582 ∂09-Mar-89 1920 CL-Cleanup-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
C03288 00583 ∂09-Mar-89 2244 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE (Version 3)
C03290 00584 ∂09-Mar-89 2314 CL-Cleanup-mailer Issue EQUALP-GENERIC
C03303 00585 ∂10-Mar-89 0916 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 7
C03313 00586 ∂10-Mar-89 1000 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 7
C03315 00587 ∂10-Mar-89 1109 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 4)
C03327 00588 ∂10-Mar-89 1211 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
C03329 00589 ∂10-Mar-89 1443 CL-Cleanup-mailer Issue PEEK-CHAR-READ-CHAR-ECHO
C03333 00590 ∂10-Mar-89 1444 CL-Cleanup-mailer Issue STREAM-ACCESS
C03335 00591 ∂10-Mar-89 1445 CL-Cleanup-mailer Issue SUBTYPEP-TOO-VAGUE
C03337 00592 ∂10-Mar-89 1446 CL-Cleanup-mailer Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER, v1
C03341 00593 ∂10-Mar-89 1452 CL-Cleanup-mailer (new) Issue DESCRIBE-UNDERSPECIFIED
C03352 00594 ∂10-Mar-89 1511 CL-Cleanup-mailer Issue PEEK-CHAR-READ-CHAR-ECHO
C03357 00595 ∂10-Mar-89 1527 CL-Cleanup-mailer
C03363 00596 ∂10-Mar-89 1529 CL-Cleanup-mailer Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER, v1
C03369 00597 ∂10-Mar-89 1553 CL-Cleanup-mailer (reply to message)
C03370 00598 ∂10-Mar-89 1553 CL-Cleanup-mailer Re: issue IN-PACKAGE-FUNCTIONALITY, version 7
C03372 00599 ∂10-Mar-89 1723 CL-Cleanup-mailer Re: Issue: CLOS-CONDITIONS (Version 4)
C03374 00600 ∂11-Mar-89 0125 CL-Cleanup-mailer Re: Issue SUBTYPEP-TOO-VAGUE
C03377 00601 ∂11-Mar-89 1452 CL-Cleanup-mailer amendments to already passed issues
C03382 00602 ∂11-Mar-89 1658 Common-Lisp-Object-System-mailer Issue: LOAD-OBJECTS (Version 3)
C03390 00603 ∂11-Mar-89 1745 Common-Lisp-Object-System-mailer Re: Issue: LOAD-OBJECTS (Version 3)
C03393 00604 ∂11-Mar-89 1938 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
C03399 00605 ∂12-Mar-89 1032 Common-Lisp-Object-System-mailer Issue: LOAD-OBJECTS (Version 3)
C03401 00606 ∂13-Mar-89 0940 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 4)
C03406 00607 ∂13-Mar-89 0946 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
C03409 00608 ∂13-Mar-89 1009 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 4)
C03413 ENDMK
C⊗;
∂11-Dec-88 1051 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Dec 88 10:51:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 DEC 88 10:45:21 PST
Date: Sun, 11 Dec 88 10:45 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, pierson@mist.encore.com, Gray@DSG.csc.ti.com,
cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <8812100131.AA07286@bhopal>
Message-ID: <19881211184511.8.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: Fri, 9 Dec 88 17:31:12 PST
From: Jon L White <jonl@lucid.com>
Larry, I would very much like to see a second alternative in this
proposal. I think the idea of a "safety-net" version of REQUIRE is
fully portable, and backwards compatible with those implementations
that hook into their own "defsystem". All the arguments against it,
that have been sent out in discussion so far, are simply confusing the
issue of REQUIRE portability with that of DEFSYSTEM portability. If
someone uses implementation A's DEFSYSTEM, his code won't be portable
to implementation B (unless B has cloned A's DEFSYSTEM). There is just
no reason to indict REQUIRE of cuplability here.
My "compromise" proposal, that Gray seemed to agree to, was to insist
that implementations which "hook" their REQUIRE into some kind of
DEFSYSTEM -- as an implementation- specific extension -- must also
provide a special variable flag that disengages any such "hook-up".
While it is true that many people will persist in writing non-portable
code, the portable use of REQUIRE to ensure that required package
definitions are "already loaded in" is of paramount importance. There is
no other portable feature to help ensure that.
I don't buy this. You can do it portably with find-package and intern.
You might claim that is gross, but I don't believe it. The point is
that REQUIRE "suggests" more than it can possibly do. It need to know
that the sub-system I depend on really is completely loaded, up and
running. Any program that is "portably" going to require the existence
of other programs takes work, it takes some sort of defsystem facility.
REQUIRE can't possibly provide that, all it can do is confuse people
into thinking that they might be getting it.
If you and Dan are amenable, I'd write the additional part -- from
previous mails, it should only take 10 or 20 minutes at most. Either
of you could probably write it too.
-- JonL --
-------
∂11-Dec-88 1549 CL-Cleanup-mailer Issue PACKAGE-CLUTTER (Version 5)
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 11 Dec 88 15:49:17 PST
Date: Sun 11 Dec 88 14:56:27-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue PACKAGE-CLUTTER (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12453663438.21.IIM@ECLA.USC.EDU>
Paragraph 2 of the Proposal section says:
" ... FBOUNDP will be false for all external symbols of the LISP package
except those documented to be functions or macros; ... "
What about special-forms? From CLtL, page 90-91, the definition of FBOUNDP
says:
"Note that FBOUNDP is true when the symbol names a special form or macro."
kab
-------
∂12-Dec-88 0929 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 12 Dec 88 09:29:22 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA00368; Mon, 12 Dec 88 12:28:03 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA10750; Mon, 12 Dec 88 11:34:43 EST
Message-Id: <8812121634.AA10750@mist.>
To: Jon L White <jonl@lucid.com>
Cc: IIM@ECLA.USC.EDU, cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
In-Reply-To: Your message of Fri, 09 Dec 88 23:37:12 -0800.
<8812100737.AA07690@bhopal>
Date: Mon, 12 Dec 88 11:34:39 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I thought I made my opposition clear enough -- that the Symbolics "status
quo" is not the status quo for the community at large; their "extension"
is not one that is fully compatible with (the obvious reading of) CLtL.
In particular, the part that of the proposal that suggests that
(make-arry n :adjustable nil)
can legitimately return an adjustable array flies in the face of the
very reason reason why the type SIMPLE-ARRAY was introduced into Common
Lisp in the first place! Listen very carefully to those implementing
Lisp on stock hardware -- ask if they think it is perfectly fine to
**** have no way whatsoever *** to guarantee getting a
non-adjustable array.
While I agree with you here, I would like to point out that the
position you are taking here strikes me as being the opposite of your
position on REQUIRE-PATHNAME-DEFAULTS. In both cases, the status quo
allows careful programmers to write portable code as in:
- Never adjust a "non-adjustable" array
- Never use REQUIRE in a context that would cause file loading
The, quite legitimate, objection to the status quo is that it makes it
_very_ likely that programmers, being human and fallible, will
accidently wind up producing non-portable code because the current
versions of these features lack adaquate (read any) portable error
checking.
∂12-Dec-88 0930 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 12 Dec 88 09:29:50 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA00392; Mon, 12 Dec 88 12:28:35 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA10740; Mon, 12 Dec 88 11:25:39 EST
Message-Id: <8812121625.AA10740@mist.>
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
In-Reply-To: Your message of Fri, 09 Dec 88 17:34:40 -0800.
<8812100134.AA07293@bhopal>
Date: Mon, 12 Dec 88 11:25:37 EST
From: Dan L. Pierson <pierson@mist.encore.com>
You meant DEFSYS, of course. Proof in point that it is DEFSYSTEM, not
REQUIRE, that is currently not in a portable state.
Of course.
I disagree in that I think both are currently not in a portable state.
In case any of this argument has given people the wrong impression, I
would strongly support almost any reasonable proposal for adding a
portable DEFSYSTEM to the standard. (I haven't put one forward
because it seems that it would have no chance). The history of Unix
for the last decade or so is a perfect demonstration of the tremendous
advantages of such a facility even if the facility itself is far short
of perfection.
While simple, standard DEFSYSTEM would be a great aid to portable CL
software distribution, it needn't compete with implementors superior
proprietary system definition packages at all. Since the prime goals
of a standard DEFSYSTEM would be portability, simplicity, and minimum
necessary functionality, it should be simple to enhance any of the
proprietary packages to cons up a portable DEFSYSTEM file when the
time came to distribute the software.
∂12-Dec-88 0929 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 12 Dec 88 09:29:31 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA00380; Mon, 12 Dec 88 12:28:24 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA10731; Mon, 12 Dec 88 11:17:09 EST
Message-Id: <8812121617.AA10731@mist.>
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
In-Reply-To: Your message of Fri, 09 Dec 88 17:31:12 -0800.
<8812100131.AA07286@bhopal>
Date: Mon, 12 Dec 88 11:17:06 EST
From: Dan L. Pierson <pierson@mist.encore.com>
If you and Dan are amenable, I'd write the additional part -- from
previous mails, it should only take 10 or 20 minutes at most. Either
of you could probably write it too.
Well, I still disagree with the substance and will almost certainly
vote against such an alternative (see Gregor's reply to your message
for my reasoning). The only thing that might change my vote would be:
1. Standardizing the control variable, and
2. Making its default value be no loading or DEFSYS interaction.
This would force all of Grey, etc.'s users to explictly enable the
non-portable feature if they wanted it. I suspect that Coral, at
least, would oppose this because they evidently document REQUIRE as
the way to enable (load) proprietary extensions such as Macintosh
graphics support.
One the other hand, I'm getting the feeling that a substatial part of
cleanup disagrees with me. Given that, and the amount of time we've
spent discussing this, I think that it is quite approptiate for you to
add a second alternative to the proposal, give it a couple of days for
cleanup comments, and send the combination to x3j13 for voting.
∂12-Dec-88 0929 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE (Version 2)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 12 Dec 88 09:29:26 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA00376; Mon, 12 Dec 88 12:28:20 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA10721; Mon, 12 Dec 88 11:08:16 EST
Message-Id: <8812121608.AA10721@mist.>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: COERCE-INCOMPLETE (Version 2)
In-Reply-To: Your message of 09 Dec 88 16:47:00 -0800.
<881209-164733-1437@Xerox>
Date: Mon, 12 Dec 88 11:08:13 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I see we have some choices:
a) remove COERCE
b) leave COERCE alone
c) extend COERCE slightly
d) extend COERCE a lot
I think (b) or (c) are the best. I'll try to say why:
...
So why don't we just define:
(coerce x 'string) == (string x)
(coerce x 'character) == (character x)
(coerce x 'pathname) = (pathname x)
(coerce x 'float) = (float x),
I agree.
In addition I think that COERCE is a dandy candidate for a generic
function, but it's my understanding that nominations for that status
haven't been opened yet.
∂12-Dec-88 0949 CL-Cleanup-mailer Issue: DEFSTRUCT-REDEFINITION (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 09:49:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 09:45:21 PST
Date: 12 Dec 88 09:44 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-REDEFINITION (version 1)
To: cl-cleanup@sail.stanford.edu
Message-ID: <881212-094521-4222@Xerox>
Perhaps we can bring a new version of this issue with us for distribution
at the January meeting.
I think the problem is that defstruct accessors are often compiled with
"knowledge" of the structure, in a way that defclass accessors are not. I
think of "defstruct" as "the most efficient defclass", i.e., I'd like to
leave maximum room for optimization. However, error-if-redefined seems a
bit too strong, e.g., if all I do is change the initial value, it doesn't
old compiled accessors or even old instances.
----- Begin Forwarded Messages -----
Date: Wed, 7 Dec 88 19:56 PST
From: Gregor.pa
Subject: Re: [masinter.pa: [cl-cleanup@sail.stanford.edu: DRAFT Issue:
DEFSTRUCT-REDEFINITION (Version 1)]]
To: masinter.pa
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: The message of 7 Dec 88 15:40 PST from masinter.pa
Message-ID: <19881208035629.7.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Sorry, but I just don't have the time to write this up just now. I am
barely managing to do what I have to do. Chapter 3 can support either
of the proposals. As I have written it now, I believe it specifies
error-if-redefined.
The only point about the relation to chapter 3 is that chapter 3 gives a
technical language for defining it. There are really three options:
error-if-redefined
error-iff-instances-exist
error-iff-used
In CLOS terminology these are:
(defmethod reinitialize-instance ((c structure-class) &rest ignore)
(error "..."))
or
(defmethod reinitialize-instance ((c structure-class) &rest ignore)
(when (class-finalized-p c)
(error "...")))
or
"The results are undefined if an instance with metaclass structure-class
is accessed after the generic function make-instances-obsolete has been
called with that class as an argument."
-------
----- End Forwarded Messages -----
∂12-Dec-88 1025 CL-Cleanup-mailer Re: discussion of Moon's comments re: ELIMINATE-FORCED-CONSING
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 10:25:20 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 10:10:42 PST
Date: 12 Dec 88 10:08 PST
From: masinter.pa@Xerox.COM
Subject: Re: discussion of Moon's comments re: ELIMINATE-FORCED-CONSING
In-reply-to: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Tue, 6 Sep
88 15:38:22 PDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881212-101042-4317@Xerox>
Joe:
On 6 Sept 88 you said, in response to a critique from Moon. "I'll submit a
modified proposal for discussion."
There were some subsequent comments on the cl-cleanup mailing list, and
we've not heard back from you. The January 1989 meeting is fast
approaching; we don't have a new writeup on this issue to mail out in
advance; if we don't hear from you, we will not have a new version to bring
there either.
Please reply if you get this note (to cl-cleanup@sail.stanford.edu), about
your plans with respect to this issue.
∂12-Dec-88 1143 CL-Cleanup-mailer RE: Issue: HASH-TABLE-ACCESS (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 11:43:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 11:31:45 PST
Date: 12 Dec 88 11:31 PST
From: masinter.pa@Xerox.COM
Subject: RE: Issue: HASH-TABLE-ACCESS (version 2)
In-reply-to: masinter.pa's message of 14 Nov 88 14:57 PST
To: vanroggen%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
Message-ID: <881212-113145-4632@Xerox>
I've not heard from Walter in weeks; I presume he is somehow unavailable.
I don't have a new version of this issue and I'm reluctant to mail out
Version 2 given comments from Sandra, GZ and JonL.
I hope we can have a new version to bring with us.
∂12-Dec-88 1212 CL-Cleanup-mailer Re: Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 12:12:08 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 11:51:07 PST
Date: 12 Dec 88 11:50 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Sat, 10 Dec 88
05:36:37 PST
To: cl-cleanup@sail.stanford.edu
Message-ID: <881212-115107-4697@Xerox>
If it is true that this issue "has already received extensive positive
review within Lucid; and has received some very positive review outside", I
have not seen those reviews.
I did see a piece of a message from Jeff Dalton included in your response
to him, but I'm missing his original message. I presume that they were not
mailed to cl-cleanup.
The only review I have is Moon's, which is fairly critical.
Against my judgement, I will release this version.
∂12-Dec-88 1444 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION (Version 4)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:34:17 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 12 Dec 88 16:45:18 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 12 Dec 88 17:30:37 EST
Date: Mon, 12 Dec 88 17:30 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: FUNCTION-COMPOSITION (Version 4)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881212-111746-4560@Xerox>
Message-Id: <19881212223051.0.BARMAR@OCCAM.THINK.COM>
Date: 12 Dec 88 11:04 PST
From: cl-cleanup@sail.stanford.edu
!
Forum: Cleanup
Issue: FUNCTION-COMPOSITION
References: None
Category: ADDITION
Edit history: 21-Jun-88, Version 1 by Pitman
05-Oct-88, Version 2 by Pitman
7-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter (additional comments)
Related-Issues: TEST-NOT-IF-NOT
Problem Description:
A number of useful functions on functions are conspicuously
absent from Common Lisp's basic set. Among them are functions
which return constant T, constant NIL, and functions which
combine functions in common, interesting ways.
Proposal (FUNCTION-COMPOSITION:NEW-FUNCTIONS):
Add the following functions:
COMPOSE &REST functions [Function]
Returns a function whose value is the same as the composition
of the given functions. eg, (FUNCALL (COMPOSE #'F #'G #'H) A B C)
is the same as (F (G (H A B C))). Also, for example, #'CAADR may
be described as (COMPOSE #'CAR #'CAR #'CDR).
(DEFUN COMPOSE (&REST FUNCTIONS)
(COND ((NOT FUNCTIONS)
(ERROR "COMPOSE requires at least one function."))
((NOT (REST FUNCTIONS))
(FIRST FUNCTIONS))
(T
(LET ((REVERSED-FUNCTIONS (REVERSE FUNCTIONS)))
(LET ((LAST-FUNCTION (FIRST REVERSED-FUNCTIONS))
(OTHER-FUNCTIONS (REST REVERSED-FUNCTIONS)))
#'(LAMBDA (&REST ARGUMENTS)
(DO ((O OTHER-FUNCTIONS (CDR O))
(VAL (APPLY LAST-FUNCTION ARGUMENTS)
(FUNCALL (CAR O) VAL)))
((NULL O) VAL))))))))
This example implementation is not consistent with the description. The
description doesn't say that at least one function is required. I think
that (COMPOSE) should return #'IDENTITY, which is the identity of the
COMPOSE function.
Stylistic note: Both instances of "NOT" in the above function definition
should be "NULL", since they are testing for a list being empty, not a
boolean being false.
barmar
∂12-Dec-88 1448 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:48:25 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 507438; Mon 12-Dec-88 17:47:27 EST
Date: Mon, 12 Dec 88 17:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 5)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <881208-182529-5127@Xerox>
Message-ID: <881212174714.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
....
A valid implimentation may have or put additional properties
on symbols (even user created symbols) as long as the
property indicators are not in the LISP, KEYWORD or USER
package.
....
The wording should be stronger. I think it should say that it will not
use any property names which are on any user-created packages (except by
inheritance). In other words, it should say that the only permissible
packages of symbols which may be used by the system for properties are
those which are initially allocated by the system for its own use (or
allocated later under some known contract between the system and user if
any implementations ever do this).
Also, SETF of GET, GETF(?), and SYMBOL-PLIST need to be explicitly excepted
for the obvious reason that they are requests by the user for the system
to violate the rules we're describing above.
∂12-Dec-88 1527 CL-Cleanup-mailer Re: Issue: SYMBOL-MACROFLET (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 15:27:43 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 15:10:04 PST
Date: 12 Dec 88 15:09 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SYMBOL-MACROFLET (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 30 Sep 88 18:47 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881212-151004-5356@Xerox>
Somehow I missed this issue on my first two passes. I think it needs a new
version to reflect the comments (from EB, Moon).
I hope I don't have *too* many copies to cart to Hawaii.
∂12-Dec-88 1546 CL-Cleanup-mailer REST-LIST-ALLOCATION (Version 3)
Received: from mist.math.uoregon.edu by SAIL.Stanford.EDU with TCP; 12 Dec 88 15:45:17 PST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Mon, 12 Dec 88 15:43:08 PDT
Received: by fog.cs.uoregon.edu; Mon, 12 Dec 88 15:42:59 PDT
Date: Mon, 12 Dec 88 15:42:59 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8812122342.AA05921@fog.cs.uoregon.edu>
To: cl-cleanup@sail.stanford.edu
Subject: REST-LIST-ALLOCATION (Version 3)
I didn't send Version 2 to this mailing list, but sent it to
Masinter instead. He requested that I make some small changes
and send the result to CL-Cleanup. Here it is.
!
Forum: Cleanup
Issue: REST-LIST-ALLOCATION
References: CLtL pp 107-108 (APPLY)
Related issues: DYNAMIC-EXTENT
Category: CLARIFICATION
Edit history: 8-Dec-88, Version 1 by Masinter
9-Dec-88, Version 2 by Clinger (add rationale, more discussion)
12-Dec-88, Version 3 by Clinger (delete bogus examples)
Problem description:
In the special case of calling a function with an &REST list via APPLY,
Common Lisp fails to specify whether a new copy of the list is freshly
allocated. For example, given
(DEFVAR *MY-LIST* '(A B C))
(DEFUN FOO (&REST X) (EQ X *MY-LIST*))
does
(APPLY #'FOO *MY-LIST*)
return T?
This issue is different from the question of the extent of "rest lists" in
the case when they *are* newly allocated which is indefinite; the issue
DYNAMIC-EXTENT also contains some proposals about extent.
Proposal (REST-LIST-ALLOCATION:NEWLY-ALLOCATED):
Specify that &REST lists are newly allocated in the case when the function
is called via APPLY.
Proposal (REST-LIST-ALLOCATION:MAY-SHARE):
Specify that the value of an &REST parameter is permitted, but not required,
to share (top-level) structure with the last argument to APPLY.
Proposal (REST-LIST-ALLOCATION:MUST-SHARE)
Specify that the value of an &REST parameter is required
to share (top-level) structure with the last argument to APPLY.
>> this needs better spec about how the args match <<
Examples:
(DEFVAR *MY-LIST* '(A B C))
(DEFUN FOO (&REST X) (EQ X *MY-LIST*))
(APPLY #'FOO *MY-LIST*) => T ;on Symbolics systems and probably
; many stock hardware implementations
This implies that
(DEFUN BAR (&REST X) (RPLACA X 'D))
(APPLY #'BAR *MY-LIST*)
*MY-LIST* => (D B C) ;on Symbolics systems and probably many stock
; hardware implementations
Another example: which of the following have the same semantics?
(setq x '(1 2 3))
[1] (apply #'foo 1 2 3 NIL)
[2] (apply #'foo 1 2 (cddr x))
[3] (apply #'foo 1 (cdr x))
[4] (apply #'foo x)
[5] (funcall #'foo 1 2 3)
Under REST-LIST-ALLOCATION:NEWLY-ALLOCATED:
[1]-[5] are equivalent.
Under REST-LIST-ALLOCATION:MAY-SHARE:
Any answer to the question is correct for some conceivable implementation.
Abstracting over implementations, this means that [1]-[5] are pairwise
non-equivalent.
Under REST-LIST-ALLOCATION:MUST-SHARE:
[1]-[4] are pairwise non-equivalent in all implementations. This proposal
leaves open the question of whether [1] is equivalent to [5].
And finally:
Should (defun foo (&rest x) ...)
behave (aside from efficiency) as if it were defined:
(defun foo (&rest G0047) ;Gensym really
(let ((x (copy-list G0047)))
...))
Rationale:
The semantics of APPLY is unclear. In consequence it is impossible
to write portable code that relies on &REST arguments sharing structure
with the last argument to APPLY. Portable code can rely on &REST arguments
*not* sharing structure with the last argument to APPLY, but only by
performing an explicit COPY-LIST on all &REST arguments; this is redundant
and inefficient in implementations where &REST arguments are newly
allocated anyway.
Current practice:
Some implementations always share. Some implementations never share.
A few may share interpreted and not share compiled, or vice versa.
Cost to Implementors:
None for MAY-SHARE, since that is the status quo. Both of the other
proposals entail a significant cost for some implementations.
If MUST-SHARE is adopted, then implementations that don't share structure
may be nearly impossible to convert. If NEWLY-ALLOCATED is adopted, then
implementations that do share will have to insert a call to COPY-LIST
inside either APPLY or &REST list handling, which will slow things down
and may be difficult as well.
Cost to Users:
No matter what, somebody gets hurt. MAY-SHARE means you have to
write awkward and inefficient code if you care. (This is already
the case for portable code.) MUST-SHARE means you have to add
explicit calls to COPY-LIST to code that assumes the contrary.
NEWLY-ALLOCATED means you have to rewrite code that assumes sharing.
Cost of non-adoption:
Great confusion over the issue. A certain amount of awkwardness and
inefficiency would remain inevitable if you want to write portable code.
Performance impact:
MUST-SHARE costs least in consing, but might slow down function call
for some implementations. MAY-SHARE lets implementations pick, has
least impact. NEWLY-ALLOCATED requires consing in cases where it
didn't before.
Benefits:
Less confusion. Improved portability.
Esthetics:
Differing, strongly held opinions.
Discussion:
The Revised3 Report on Scheme specifies that the equivalent of a
&REST argument must be a newly allocated list, to avoid precisely this
problem.
The argument for MUST-SHARE is that copying is inefficient, so
&REST should never cause copying of a list passed to it from APPLY.
Functions that desire a new copy can just call COPY-LIST.
Two arguments for MAY-SHARE are:
1. In no other place does Common Lisp automatically unshare structure,
except when the user is explicitly modifying the structure (as in REMOVE).
Making APPLY automatically unshare would be a semantic wart.
2. If APPLY copies its last argument, recursive programs that receive an
&REST argument and pass it to APPLY become inefficient. A linear time
algorithm can change to a quadratic time algorithm. While the efficiency
could be regained through compiler flow analysis in many cases, it's
better not to put the inefficiency into the language in the first place.
The DYNAMIC-EXTENT proposal would allow &REST lists
that were "newly allocated" to have dynamic extent if they were
to be passed down via APPLY. This puts the burden in the
right place.
Two (closely related) arguments for NEWLY-ALLOCATED:
1. The programmer's model of function calling is simpler: functions
take arguments, and any two calls that pass the same arguments to the
same function are equivalent. The MAY-SHARE and MUST-SHARE proposals
require a model in which functions generally take their arguments in
the form of a list, and the extent to which that list shares structure
with other lists in the system becomes an important part of the
semantics of a function call.
2. It's not only smashing a &rest argument that's a problem, it's
smashing any list that has been given as the last argument to APPLY as
well. Consider the following in an implementation that doesn't copy
the last argument to APPLY when it is passed as a &rest argument:
> (defvar *message*)
*MESSAGE*
> (defun set-message (&rest mess)
(setq *message* mess))
SET-MESSAGE
> (let ((winner (list 'a 'winner)))
(apply #'set-message winner)
(setf (cdr winner) (list 'loser))
winner)
(A LOSER)
Is *message* (A WINNER) or (A LOSER)? (It might be
(#<DTP-LOCATIVE 76123756> #<DTP-ODD-PC 12313453> ...)
but that's a different problem.) This suggests that once a list has
been given as the last argument to APPLY it is no longer OK to modify
it.
Gail Zacharias talked about the common idiom of simply doing a COPY-LIST
on every &rest argument, to insure some normalcy. Her reasoning seems
to bolster the case for those who claim that the current CL semantics
(MAY-SHARE) are deficient:
Subject: &REST Lists
Date: 24 Mar 88 12:23:15 EST (Thu)
From: gz@spt.entity.com (Gail Zacharias)
. . .
If Common Lisp doesn't require unshared &rest lists, then I think
it must provide a declarative version of this idiom so the COPY-LIST can
be portably avoided when it's redundant. Seems to me that the fact that
this is a common case where users find a need for conditionalization
indicates a real deficiency in Common Lisp's specification.
. . .
So we have a responsibility to resolve the very thorny issue
of REST-LIST-ALLOCATION.
∂12-Dec-88 1748 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Dec 88 17:48:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 507596; Mon 12-Dec-88 20:48:08 EST
Date: Mon, 12 Dec 88 20:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881212-160109-5511@Xerox>
Message-ID: <19881213014819.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
[X3J13 removed]
I approve this, but there are some obvious mistakes:
Why is RANDOM-STATE missing from the list of built-in types? Probably others
are missing as well, I did not check the list carefully.
(SUBTYPEP (TYPE-OF x) (CLASS-OF x)) => T T for all x, seems to
have been intended but is not actually said. I think this should
be added to the proposal section.
The first three points in the proposal section are identified with
letters, but the last three points are not.
Re the discussion section:
The comment about the relation of CLASS-OF and TYPE-OF, while it may be
true, only indicates confusion in an earlier CLOS spec and detracts from
understanding the point of this proposal.
If you want "to eliminate the possibility that TYPE-OF might return a
non-portable implementation-specific value" you will have to define
the concept of portable objects versus implementation-dependent objects,
since obviously an implementation that has an entirely new kind of
object cannot return a portable type-specifier for that object. Also what
about implementations that have implementation-dependent subtypes of
built-in types, especially if those subtypes are defined with DEFSTRUCT
or DEFCLASS -- the spec simultaneously requires TYPE-OF to return the
class name or structure name, and to return a portable value distinct
from the class or structure name. For a concrete example, Genera has an
implementation-dependent subtype of PATHNAME for each type of file
system supported, and TYPE-OF returns the class name. I think the
proposed implementation recommendation cannot be portably specified
and hence should be discarded.
∂12-Dec-88 1755 X3J13-mailer Issue: TAILP-NIL (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Dec 88 17:55:38 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 507602; Mon 12-Dec-88 20:55:04 EST
Date: Mon, 12 Dec 88 20:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)
To: x3j13@sail.stanford.edu
cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: <881212-151820-5387@Xerox>
Message-ID: <19881213015522.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Correction: Contrary to what the current practice section says,
the proposal TAILP-NIL:T is not what Symbolics Genera does. In
fact I know of no implementation that does what the proposal says.
However, I support the proposal anyway, because I think it's the
most consistent with the rest of Common Lisp.
∂12-Dec-88 2019 CL-Cleanup-mailer Issue: STREAM-INFO (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Dec 88 20:19:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 507662; Mon 12-Dec-88 23:18:59 EST
Date: Mon, 12 Dec 88 23:19 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 6)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881209-100319-6354@Xerox>
Message-ID: <19881213041909.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
[X3J13 removed]
Approved only if the name-changing amendment mentioned in the mail passes.
The writeup incorrectly states that Newline is not a standard character; I
suspect someone has confused "standard" with "graphic". If for some reason
the proposal is edited again, this should be fixed.
∂13-Dec-88 0831 CL-Cleanup-mailer Issue: TAILP-NIL (Version 5)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 08:31:02 PST
Return-Path: <barmar@fafnir.think.com>
Received: from sauron.think.com by Think.COM; Tue, 13 Dec 88 10:38:42 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 13 Dec 88 11:25:07 EST
Date: Tue, 13 Dec 88 11:25 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: TAILP-NIL (Version 5)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: <19881213015522.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19881213162522.6.BARMAR@OCCAM.THINK.COM>
Date: Mon, 12 Dec 88 20:55 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Correction: Contrary to what the current practice section says,
the proposal TAILP-NIL:T is not what Symbolics Genera does. In
fact I know of no implementation that does what the proposal says.
However, I support the proposal anyway, because I think it's the
most consistent with the rest of Common Lisp.
I just tried all the examples in the mailing, and they all had the
results that they were supposed to. How does Genera differ from
TAILP-NIL:T?
barmar
∂13-Dec-88 0856 CL-Cleanup-mailer Issue: TAILP-NIL (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88 08:56:24 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 507776; Tue 13-Dec-88 11:52:01 EST
Date: Tue, 13 Dec 88 11:52 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)
To: Barry Margolin <barmar@Think.COM>
cc: cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: <19881213162522.6.BARMAR@OCCAM.THINK.COM>
Message-ID: <19881213165206.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Tue, 13 Dec 88 11:25 EST
From: Barry Margolin <barmar@Think.COM>
How does Genera differ from TAILP-NIL:T?
Genera uses EQ, the proposal uses EQL (maybe you didn't notice that).
Since I don't believe EQ belongs in Common Lisp in the first place, I
agree that any system function that uses EQ as a test is wrong and
should be using EQL, which is why I support the proposal. (EQ is only
in Common Lisp as a concession to implementors who haven't figured out
how to implement EQL efficiently (it isn't hard), or hadn't figured it
out yet in 1984).
∂13-Dec-88 1130 CL-Cleanup-mailer New issue: COMPLEX-ATAN-BRANCH-CUT
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 11:30:21 PST
Received: from fafnir.think.com by Think.COM; Tue, 13 Dec 88 13:42:15 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 13 Dec 88 14:28:45 EST
Received: by verdi.think.com; Tue, 13 Dec 88 14:27:20 EST
Date: Tue, 13 Dec 88 14:27:20 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8812131927.AA25890@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: New issue: COMPLEX-ATAN-BRANCH-CUT
Forum: Cleanup
Issue: COMPLEX-ATAN-BRANCH-CUT
References: CLtL p.208, 212
Related issues: IEEE-ATAN-BRANCH-CUT
Category: CHANGE
Edit history: Version 1, 13-Dec-88, Steele
Problem description:
The formula that defines ATAN results in a branch cut that is at
variance with the recommendations of Prof. W. Kahan and with the
implementations of that function in many computing systems and
calculators.
Proposal (COMPLEX-ATAN-BRANCH-CUT:TWEAK):
Replace the formula
arctan z = - i log ((1+iz) sqrt (1/(1+z↑2)))
with the formula
arctan z = (log (1+iz) - log (1-iz)) / (2i)
This leaves the branch cuts pretty much in place; the only change is
that the upper branch cut (on the positive imaginary axis above i)
is continuous with quadrant I, where the old formula has it continuous
with quadrant II.
Examples:
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Current
(atan #c(0 2)) => #c(1.57... -0.549...) ;Proposed
Note: 1.57... = pi/2, and 0.549... = (log 3)/2.
Rationale:
Compatibility with what seems to be becoming standard practice.
Current practice:
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Symbolics CL
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Allegro CL 1.1 (Macintosh)
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Sun-4 CL 2.1.3 of 10-Nov-88
(atan #c(0 2)) => #c(1.57... -0.549...) ;Sun CL 2.0.3 of 30-Jun-87
(atan #c(0 2)) => #c(1.57... 0.549...) ;KCL of 3-Jun-87
Note that in KCL the upper branch cut is thus continuous with
quadrant I, but its lower branch cut is continuous with quadrant III!
Cost to Implementors:
ATAN must be rewritten. It is not a very difficult fix.
Cost to Users:
It is barely conceivable that some user code could depend on this.
Note that the proposed change invalidates the identities
arctan i z = i arctanh z
and arctanh i z = i arctan z
on the upper branch cut.
The compatibility note on p. 210 of CLtL gave users fair warning that
a change of this kind might be adopted.
Cost of non-adoption:
Incompatibility with HP calculators.
Benefits:
Numerical analystsmay find the new definition easier to use.
Esthetics:
A toss-up, except to those who care.
Discussion:
Steele has sent a letter to W. Kahan at Berkeley to get any last
comments he may have on the matter.
Paul Penfield of MIT, after whose article the Common Lisp branch
cuts were originally patterned, endorses this change.
∂13-Dec-88 1131 CL-Cleanup-mailer New issue: IEEE-ATAN-BRANCH-CUT
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 11:31:13 PST
Received: from fafnir.think.com by Think.COM; Tue, 13 Dec 88 13:43:05 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 13 Dec 88 14:29:36 EST
Received: by verdi.think.com; Tue, 13 Dec 88 14:28:10 EST
Date: Tue, 13 Dec 88 14:28:10 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8812131928.AA25893@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: New issue: IEEE-ATAN-BRANCH-CUT
Forum: Cleanup
Issue: IEEE-ATAN-BRANCH-CUT
References: CLtL p.203-214
Related issues: COMPLEX-ATAN-BRANCH-CUT
Category: CHANGE
Edit history: Version 1, 13-Dec-88, Steele
Problem description:
If an implementation provides a floating-point minus zero as well as a
floating-point plus zero, most notably as in IEEE 754 floating-point
arithmetic, then slight adjustments in the branch cuts of transcendental
functions are appropriate.
If there is a minus zero and a plus zero, then *no* complex number
is actually "on the axis" whether real or imaginary. Instead,
numbers of the form x+0i and x-0i straddle the real axis, and those
of the form 0+xi and -0+xi straddle the imginary axis. Branch cuts
that lie on the axes therefore run between such numbers, and directions
of continuity are not an issue.
Proposal (IEEE-ATAN-BRANCH-CUT:SPLIT):
We propose to redefine the branch cut for two-argument ATAN, covering
the cases where there is or is not a minus zero, and then redefine *all*
other functions that have branch cuts in terms of two-argument ATAN.
Specifically, we first define PHASE in terms of two-argument ATAN,
and complex ABS in terms of real SQRT (which has no branch cut problems);
then define complex LOG in terms of PHASE, ABS, and real LOG; then define
complex SQRT in terms of LOG; and then define all others in terms of these.
When I write Lisp expressions, I mean them to be taken as mathematical
formulas that could be implemented in other ways for improved accuracy.
(1) If there is no minus zero, two-argument ATAN behaves as in CLtL.
If there is a minus zero, then some cases are modified:
Condition result
y=+0 x>0 +0
y=-0 x>0 -0
y=+0 x<0 +pi
y=-0 x<0 -pi
y=+0 x=+0 +0
y=-0 x=+0 -0
y=+0 x=-0 +pi
y=-0 x=-0 -pi
The range of two-argument atan therefore includes -pi in this case.
Note that the case y=0 x=0 is an error in the absence of minus zero,
but is defined in the presence of minus zero.
(2) (PHASE X) = (ATAN (IMAGPART X) (REALPART X)), as before, but now
the range of PHASE may include -PI if there is a minus zero.
(3) (ABS X) = (SQRT (+ (* (REALPART X) (REALPART X))
(* (IMAGPART X) (IMAGPART X)))), as before
(4) (LOG X) = (COMPLEX (LOG (ABS X)) (PHASE X))
(5) (SQRT X) = (EXP (/ (LOG X) 2))
(6) For EXPT, ASIN, ACOS, ATAN, ASINH, ACOSH, ATANH use the formulas
in CLtL pp. 211-213, but use the formulas (1-5) above as the
definitions of LOG and SQRT in order to determine the branch cuts
properly.
Examples:
(LOG #c(-1.0 +0.0)) => #c(0.0 3.14159...) ;Current
(LOG #c(-1.0 -0.0)) => #c(0.0 3.14159...) ;Current
(LOG #c(-1.0 +0.0)) => #c(0.0 3.14159...) ;Proposed (= current)
(LOG #c(-1.0 -0.0)) => #c(0.0 -3.14159...) ;Proposed (conjugate)
Rationale:
The current specification ignores some natural consequences of IEEE
floating-point arithmetic. The proposed specification produces results
more natural to that arithmetic.
Current practice:
Of implementations that support a minus zero that I have checked,
such as Sun-4 CL 2.1.3 of 10-Nov-88 and Symbolics CL, all follow
the current CLtL specification.
The IEEE trig library atan2 routine written by K.C. Ng (with the advice
or supervision of W. Kahan, I believe), and distributed with BSD UNIX
(it is file /usr/src/usr.lib/libm/IEEE/atan2.c on my machine) follows
this proposal for treatment of minus zero.
Cost to Implementors:
Some of the trig routines will require some rewriting. Probably certain
tests that are now written using ZEROP need to be rewritten to use
FLOAT-SIGN instead.
Cost to Users:
It is barely conceivable that some user code could depend on this.
Probably there is no cost.
The compatibility note on p. 210 of CLtL gave users fair warning that
a change of this kind might be adopted.
Cost of non-adoption:
Unnatural treatment of some functions on machines supporting IEEE
floating-point arithmetic.
Benefits:
Natural treatment, etc.
Esthetics:
A toss-up, except to those who care.
Discussion:
Steele has sent a letter to W. Kahan at Berkeley to get any last
comments he may have on the matter.
∂13-Dec-88 1446 CL-Cleanup-mailer Issues: SETF-PLACES, SETF-FUNCTION-VERSUS-MACRO
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88 14:46:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508073; Tue 13-Dec-88 17:46:21 EST
Date: Tue, 13 Dec 88 17:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issues: SETF-PLACES, SETF-FUNCTION-VERSUS-MACRO
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <8812091618.AA01151@defun.utah.edu>,
<881209-011330-5598@Xerox>,
<881209-005847-5576@Xerox>,
<881209-005650-5575@Xerox>,
<881130-185833-3618@Xerox>,
<19881201011953.3.GREGOR@PORTNOY.parc.xerox.com>,
<8811301926.AA01386@mist.>,
<881130-103422-2216@Xerox>,
<8811300836.AA03401@bhopal>,
<8811300333.AA02997@bhopal>,
<2805815733-10120696@Kelvin>,
<8811290708.AA00511@bhopal>,
<8811290702.AA00498@bhopal>,
<8811290644.AA00476@bhopal>,
<8811281729.AA10535@rainbow-warrior>,
<881128-102707-1360@Xerox>,
<19881123004923.5.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<2805237539-1438981@Kelvin>
Message-ID: <19881213224631.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I have re-read all of the referenced messages on SETF-PLACES and
SETF-FUNCTION-VERSUS-MACRO. My opinion has not changed. I don't
consider that any of my comments on SETF-PLACES have been adequately
addressed; that is, the version of SETF-PLACES that was mailed to X3J13
was the same as the original version, and the mail response to my
comments did not convince me that no changes to the proposal were
appropriate.
I agree with Gray that if the problem is with making SYMBOL-FUNCTION
accept arguments that are not symbols, a better approach than
UNDERLYING-NAME is to add FDEFINITION and its related primitives,
leaving SYMBOL-FUNCTION alone. This provides a clear layering of
primitives, instead of this strange (to me anyway) concept of a
translation that may or may not actually translate. I wasn't at the
October X3J13 meeting, but from the description of the amendment at that
meeting, what Gray said seems to be more like what X3J13 was asking for.
We have been discussing this stupid issue for almost a year and a half.
I certainly hope the January X3J13 meeting can come to a decision.
∂13-Dec-88 1509 CL-Cleanup-mailer Issue: PACKAGE-DELETION (Version 5)
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 13 Dec 88 15:08:58 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM
by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88)
id AA24500; Tue, 13 Dec 88 17:07:45 CST
Posted-Date: Tue, 13 Dec 88 17:06:12 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA11821; Tue, 13 Dec 88 17:06:12 CST
Date: Tue, 13 Dec 88 17:06:12 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8812132306.AA11821@pavo.src.honeywell.com>
To: cl-cleanup@sail.stanford.edu
Cc: masinter.pa@Xerox.COM
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 8 Dec 88 20:40 PST <881208-204059-5304@Xerox>
Subject: Issue: PACKAGE-DELETION (Version 5)
....
If the designated package is used by other packages, a correctable
error is signalled. ...
"continuable error"
After this operation completes, the contents of the symbol-package
slot of any symbol homed in the deleted package is unspecified; ...
symbol S homed in pkg P == (eq P (symbol-package S)) ?
Perhaps;
If package P was the value of (symbol-package S) then P is killed, it is
unspecified what the value of (symbol-package S) is.
∂13-Dec-88 1606 CL-Cleanup-mailer Issue: TAILP-NIL (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88 16:06:23 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508117; Tue 13-Dec-88 19:05:23 EST
Date: Tue, 13 Dec 88 19:05 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)
To: Masinter.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881212-151820-5387@Xerox>
Message-ID: <881213190509.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 12 Dec 88 15:17 PST
From: cl-cleanup@sail.stanford.edu
Sender: masinter.pa@Xerox.COM
Issue: TAILP-NIL
...
Discussion:
...
It was suggested more than once by more than one cleanup
committee member that we remove TAILP from the language
"since almost nobody uses it".
For the record, at least one member of the cleanup committee thinks
this sentence is
Irrelevant. Removing the operator would be gratuitous.
Inflammatory. It seems to raise the possibility of removing TAILP,
when in fact since such a move would be quickly labeled gratuitous,
only provides fodder for those who wish to muddy the water and avoid
the real issues under discussion.
Unfounded. No evidence is presented to support the claim that almost
nobody uses it. Indeed, it has been repeatedly shown that if an
operator is used at all, we have no way of evaluating what it
means for the operator to be "used a lot" (lines of code, number
of executed funcalls, dollars behind products using, ...). It happens
that this claim's probably true, but as a point of style we oughtn't
be in the habit of making anonymous, unsubstantiated claims about usage
patterns, or especially of encouraging that decisions be made based on
such claims.
Shooting in the Dark. Even if an operator were not often used by some
metric(s), the suggestion that the only or best way to deal with it
is to remove it is random. There are equally good reasons to believe
that the operator would be both useful and more heavily used if its
definition were ammended to accomodate serious uses.
I, for one, have found that nearly every time I think LDIFF would
suffice, the EQL test (rather than EQUAL), and its failure to take
a test argument, has screwed me -- causing me to do what I have always
felt is needless rewrite. I have only rarely needed TAILP and I can't
remember if I ended up actually using it or not -- I'd suspect that
the constraints on it make it next to useless.
The point I want to stress is that the fact that LDIFF and TAILP have
not been what I've needed does not mean that I've not needed to find
the difference of two lists or to find if something was a subtail of
something else. The problem for me has not been that these -operations-
are useless (or nearly so) -- but rather that these -operators- are.
The cure is not necessarily to flush the operators -- it might well be
to fix them. I certainly think fixing them is the correct solution.
Only in writing this message did I become cognizant of the significance of
my problems with LDIFF and its relation to TAILP.
Btw, I just looked up LDIFF and its description suffers from a similar
non-clarity about dotted lists to that which TAILP suffers from. It
clearly admits NIL as a possible sublist, but it doesn't really treat
atoms. So, the status quo is that the relationship between LDIFF and TAILP
is not clear, the proposal TAILP-NIL:NIL would have definitely made them
incompatible, TAILP-NIL:T makes them more conceptually compatible, but
without further clarification, they will not really be compatible.
Based on this, I'm strongly tempted to suggest that we should ...
- Expand this proposal to deal with LDIFF.
- Elaborate this proposal to add a :TEST argument to both
operators. [Clearly a :TEST argument of EQUAL may be dramatically
slower, but if the alternative is to write a LOOP calling EQUAL,
the net effect is the same and the only question is how much coding
I have to do and how much the system will do for me.]
So there! That should teach you to add "harmless" little additions to the
discussion at the last minute. :-)
∂13-Dec-88 1645 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88 16:45:17 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508133; Tue 13-Dec-88 19:44:31 EST
Date: Tue, 13 Dec 88 19:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 9)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881208-215519-5376@Xerox>
Message-ID: <881213194417.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 8 Dec 88 21:54 PST
From: masinter.pa@Xerox.COM
I've attempted to make the edits that JonL suggested in
his message of 18-Oct-88.
To my great relief, these changes look generally quite fine.
Thanks, Larry.
I wish this were shorter, e.g., that we could say what we have
to say with less Discussion. I'm sorry I haven't the courage
to tackle it.
Well, My training in writing for newspapers says this is not really much
of an issue as you might think. As long as the presentation is in
"inverse pyramid style" (order of diminishing importance), people can
stop reading when they've gotten the important stuff if they think the
writeup is too long. Of course, the poor guy we trick into Xeroxing copies
of all these issues and carry them halfway around the world to the meeting
(possibly in the other order) may not agree...
I have one substantive comment, by the way:
Issue: PROCLAIM-LEXICAL
Edit history:
...
Version 9 by Masinter 8-Dec-88 (make JonL's changes)
...
Proposal (PROCLAIM-LEXICAL:LG):
...
Clarify that a dynamic binding of a variable creates a new binding
in the dynamic environment (D) leaving the global environment (G)
unaffected.
...
In the previous version, I used the verb "Define" for this, not "Clarify"
here. "Clarify" is technically ok but only if you understand how the formal
global environment (G) described here potentially differs from the global
environment actually implemented in the running Lisp (i.e., if you
understand why this description does not preclude shallow binding).
I had preferred the word "Define" because it makes people read more closely,
and because some people may not see this as a simple clarification.
I don't think it's worth re-issuing the proposal, but I do think it's
something we should be aware of in case it leads to confusion in the
open discussion -- so we can head it off quickly.
Overall, I'm extremely pleased with this how this writeup ended up.
I'm crossing my fingers that it will be well-received.
∂13-Dec-88 1800 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88 18:00:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508169; Tue 13-Dec-88 20:59:28 EST
Date: Tue, 13 Dec 88 20:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT (Version 5)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881212-103904-4431@Xerox>
Message-ID: <19881214015936.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I'm sorry I got behind reading the mail on this topic. There are enough
mistakes in this released-to-X3J13 version (even though it is
considerably improved over my last version) that a line by line
commentary seems necessary. Sorry about the length. I've avoided
commenting on typos that don't affect the meaning, except to put -> in
the margin, to save space.
I'd volunteer to fix the writeup except that, as noted below, I can't
think of any implementation-independent way to say what I think the
MEDIUM proposal was intended to say, but does not actually say.
Issue: EXIT-EXTENT
References: CATCH, THROW,
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Related issues: UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: ... Version 5 of UNWIND-PROTECT-NON-LOCAL-EXIT, 23-May-88 ...
Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter, minor edits
Version 3, 7-Oct-88, by Moon, wording improvements
Version 4, 7-Dec-88, by Masinter, add MEDIUM from
UNWIND-PROTECT-NON-LOCAL-EXIT, discussion.
Version 5, 12-Dec-88, Masinter, clarify MINIMAL allows MEDIUM
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
For example, at what point is it no longer possible to RETURN-FROM
a particular BLOCK?
(Terminology: In this issue writeup, the noun "exit" is
-> refera to the thing that can be exited from, rather than the
act of exiting.
That would be a good idea, but in fact the writeup still uses the word
"exit" to refer both to the door and to the act of walking out the door.
I guess the sentence is technically true, since the latter use is a verb
rather than a noun. It would be better to use only "transfer of control"
to refer to the act of walking out the door.
When the extent of an exit has ended, it is
no longer legal to exit from it. This is different from
the scope of the exit. For example, a BLOCK has lexical
-> scope but dynamic extent; a the scope of a CATCH--the
visibility of the CATCH tag to corresponding THROWs--
could differ from the extent of the CATCH.)
The problem arises when there are nonlocal exits from the
"cleanup" clauses of an UNWIND-PROTECT.
There are three cases of interest:
(1) Normal exit from a CATCH, BLOCK, or TAGBODY, or equivalent such as
PROG. A normal exit occurs when the last form in the body of one of
these constructs completes its evaluation without performing a transfer
of control.
(2) Nonlocal exit from the target of a THROW or RETURN. A nonlocal exit
occurs when control is transferred by THROW, RETURN, or RETURN-FROM.
The CATCH or BLOCK named in the THROW, RETURN, or RETURN-FROM is
referred to as the target. The TAGBODY containing the tag named by a
GO is also referred to as the target, but GO differs from the other
nonlocal control transfer operators because GO does not exit its target.
-> For example,
(3) Abandonment of an exit passed over by THROW, RETURN, or GO. A
CATCH, BLOCK, or TAGBODY that is dynamically nested inside the target of
a nonlocal transfer of control is said to be passed over when control is
transferred to the target. The target itself is not said to be passed
over.
For example, in
(block testem
(when (zilched) (return-from testem nil))
(when (zorked) (throw 'uh-oh))
(format t "Neither zilched nor zorked."))
if (zilched) returns true, the block testem is exited via a
'nonlocal exit'. If (zorked) returns true, the block testem
is 'passed over'. Otherwise, the block is exited normally.
The terms "normal exit", "target", and "passed over" will be used with
these meanings for the remainder of the discussion.
CLtL is unambiguous about case 1. In case 2, the extent could end
anywhere from the time the THROW or RETURN commences, until the time the
transfer of control is completed. In case 3, the extent could end
anywhere from the time the THROW, RETURN, or GO commences, until the
time the transfer of control is completed. In case 2, it is clear that
the extent of the target ends before the transfer of control completes,
since a block cannot be exited twice, but it is not made clear whether
the extent ends before or after execution of UNWIND-PROTECT cleanup
forms. CLtL says nothing about case 3, although a note on p.38 implies
that the extent of a passed-over exit should end no later than the end
of the extent of the target exit. It would make sense for the extent
of an exit passed-over by GO to end no later than when the transfer of
control is completed, but CLtL says nothing about this.
!
Proposal (EXIT-EXTENT:MINIMAL):
The dynamic extent of an exit, whether target or passed-over, ends as
soon as the THROW, RETURN, or GO commences. In the language of the
implementation note on p.142, the extent ends at the beginning of the
second pass. It is an error for an UNWIND-PROTECT cleanup form executed
during a nonlocal transfer of control to attempt to use an exit whose
dynamic extent ended when the nonlocal transfer of control commenced.
Actually this should just say "It is an error to attempt a transfer of
control to an exit whose dynamic extent has ended." It doesn't really
matter when it ended nor exactly who attempts the transfer of control.
Note that this does not affect the extent of the binding of CATCH
tags; that is, under this proposal, a THROW to a CATCH which was
already in the process of being exited would be an error.
I think the word "extent" in the first line of this paragraph should
have been "scope", but I can see how reasonable people might disagree.
A couple of places later in the writeup use "scope" in that way in
connection with CATCH, though.
This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL. A program that presumed a longer extent
would be in error. Implementations may support longer extents for
exits than is required by this proposal; in particular, an
implementation which allowed the larger extent of the MEDIUM
proposal below would still conform.
Proposal (EXIT-EXTENT:MEDIUM):
The dynamic extent of an exit, whether target or passed-over, ends
only after the exit is complete.
I doubt that that is what you intended to say. For example,
(block one
(let ((f nil))
(unwind-protect
(block two
(flet ((g () (return-from two 2)))
(setq f #'g)
(return-from one 1)))
(funcall f))))
Under MINIMAL, this is an error because the block named two is passed
over by the return-from one before the return-from two is executed.
Under MEDIUM, this is not an error because at the time of the funcall f,
the exit is not complete and so the dynamic extent of the block named
two has not yet ended. It either returns 2 or goes into an infinite
loop, depending on what it means to exit twice out of an UNWIND-PROTECT.
Probably this intended to say something about how the dynamic extent of
a passed-over exit ends when control reaches a frame that was
established before the exit was established. I don't know how to say
that in an implementation-independent way. This difficulty in defining
a clear semantics for passed-over exits is exactly why I have always
favored MINIMAL, which constrains portable programs maximally and
constrains implementations minimally (which allows us to say as little
as possible about the implementation).
I think we must only vote on what proposals actually say, not on what we
guess they might have been intended to say. We can of course amend them
to say something different and then vote on them.
A transfer of control from within an UNWIND-PROTECT cleanup form
to a point outside of the UNWIND-PROTECT causes the original control
transfer which initiated the execution of the cleanup forms to be
-> abandonded.
During the execution of the cleanup forms of an UNWIND-PROTECT a
non-local exit to a point outside of the scope of the UNWIND-PROTECT,
-> but still within the dynamic scope of of the target of the original
non-local exit succeeds, and the original pending exit is discarded.
Where an UNWIND-PROTECT cleanup form attempts a non-local exit to a
point outside the original non-local exit, control is passed to the
outer exit (and the pending original non-local exit is discarded.)
In no case will UNWIND-PROTECT cleanup forms ever be attempted more
than once.
This can't be true, since everyone agrees that
(unwind-protect nil
(loop (print 1)))
prints 1 more than once. Also if the UNWIND-PROTECT is entered more
than once, it cleanup forms can of course be called more than once.
I think I know what you intended to say, but that isn't what you
actually said. I'm not sure why this needs to be in the proposal at all
once the problem I pointed out above is fixed, so maybe it would be
simpler just to remove it.
!
Examples:
-> Each of the following programs are an error under either
proposal:
;; Error: BLOCK has normal exit before RETURN
(funcall (block nil #'(lambda () (return))))
;; Error: normal exit before GO
(let ((a nil))
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
;; Error: TAGBODY is passed over, before GO
(funcall (block nil
(tagbody a (return #'(lambda () (go a))))))
-> Each of these programs are an error under MINIMAL, but
not under MEDIUM:
;;returns 2 under MEDIUM, is error under MINIMAL
(block nil
(unwind-protect (return 1)
(return 2)))
;;returns 2 under MEDIUM, is error under MINIMAL
(block a
(block b
(unwind-protect (return-from a 1)
(return-from b 2))))
;; returns 2 under MEDIUM, is error under MINIMAL
(catch nil
(unwind-protect (throw nil 1)
(throw nil 2)))
;; returns 2 under MEDIUM, is error under MINIMAL
(catch 'a
(catch 'b
(unwind-protect (throw 'a 1)
(throw 'b 2))))
;; An error under MINIMAL because the catch of b is passed over by
;; the first throw, hence portable programs must assume its dynamic extent
;; is terminated. The catch is not yet disestablished and therefore it
;; is the target of the second throw.
;; the following is an error under MINIMAL; the extent of the
;; inner catch terminates as soon as the throw commences, even
;; though it remains in scope. Thus, the throw of :second-throw
;; sees the inner catch, but its extent has ended.
;; under MEDIUM, it prints "The inner catch returns :second-throw"
;; and then returns :outer-catch.
(catch 'foo
(format t "The inner catch returns ~s.~%"
(catch 'foo
(unwind-protect (throw 'foo :first-throw)
(throw 'foo :second-throw))))
:outer-catch))
The following program is not an error. It returns 10. The inner
catch of a is passed over, but this is not case 3 because that catch
is disestablished before the throw to a is executed.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
The way MEDIUM is actually written, this seems to return 11 under
MEDIUM, because the throw to a goes to the inner catch. But I think you
intended for it to return 10.
The following cases are errors under MINIMAL, and have
the following interpretation under MEDIUM:
The second case is not an error under MINIMAL. It behaves
identically in MINIMAL and MEDIUM.
In
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
the pending exit to tag FOO is discarded by the second THROW
to BAR and the value 4 is transfered to (CATCH 'BAR ...),
which returns 4. The (CATCH 'FOO ...) then returns the 4
because its first argument has returned normally.
XXX is not printed.
In
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
the value 4 is returned from the (CATCH 'BAR ...); XXX is not printed.
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. It is not an error, even though the
BAR tag is not found within the local dynamic scope of
I don't know what a "local dynamic scope" is.
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found outside the scope of the target of the
pending THROW to FOO.
Rationale:
For MINIMAL: Giving exits the smallest extent consistent with CLtL
maximizes freedom for implementations; there are few applications,
if any, that require a longer extent.
-> For MEDIUM: Giving exits a longer exent has cleaner semantics.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target block or catch at the moment the values are returned, and
end the extent of a passed-over exit at the moment the THROW, RETURN, or
GO commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, the extent of a target exit lasts until the
exit has been completed; in those implementations, it is possible for a
throw or non-local exit to be effectively "stopped" by an UNWIND-PROTECT
cleanup clause that performs a nonlocal transfer of control to a
passed-over exit.
Some implementations crash or otherwise generate garbage code for
non-local exits from cleanup clauses of UNWIND-PROTECT.
Cost to Implementors:
No currently valid implementation will be made invalid by the MINIMAL
proposal. Some implementors may wish to add error checks if they
do not already have them.
MEDIUM would have a high cost for those implementations that currently
have shorter exent.
Cost to Users:
Most user programs don't do this, so there is likely little cost
of converting existing code in any case. In any case, current implementations
differ enough that this issue ostensibly does not
affect current portable programs. Some users might have code that
relies on the "unstoppable loops" that can be created with the MEDIUM
proposal.
Benefits:
Either proposal would make Common Lisp more precisely defined.
Cost of non-adoption :
The semantics of exits will remain ambiguous.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
This issue is controversial. It was first discussed under the issue
named UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT. The issue was recast as
the more global one of "extent of exits" rather than the specific
one of "what happens if a cleanup in an UNWIND-PROTECT does a non-
local exit", but the problem cases for both topics are the same.
The goal of the MINIMAL proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. The MEDIUM proposal
defines the extent of an exit to end at the last moment possible
within some particular reference implementation. It has
a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal, not considered
here, would duck the issue by outlawing all nonlocal exits from UNWIND-PROTECT
cleanup forms. That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
An argument for the MEDIUM proposal was made based on the example:
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
Since there is no reason for FOO and BAR not to be treated interchangably,
calling this an error would be inappropriate.
This is no argument against the MINIMAL proposal. Suppose FOO and BAR
are to be treated interchangeably. Then the above example should be
equivalent to
(block foo
(unwind-protect
(return-from foo 'foo)
(return-from foo 'bar)))
In fact these two examples are equivalent under both proposals. Under
MEDIUM they both return BAR. Under MINIMAL they are both errors.
It was argued that the MINIMAL proposal is equivalent to practically
outlawing non-local exits from UNWIND-PROTECT cleanup clauses, because
there is no general way to determine the target of the nonlocal exit
that caused the cleanup clause to be invoked.
CLtL never says in what dynamic environment cleanup forms of
UNWIND-PROTECT are executed. The implementation note on p.142 may have
been intended to cover this, but since it doesn't define the term
"frame" that it uses, it doesn't actually say anything. The extent of
dynamic-extent entities other than exits should be the
subject of a separate proposal. It was argued that the likely
resolution of those issues would be more consistent with the
MEDIUM proposal than MINIMAL.
The following example was offered as an argument against MINIMAL. Given:
(block nil
(handler-case
(unwind-protect (return)
(error "foo")) ;probably an error, under the proposal
(error ()
(print "foo"))))
If the ERROR handler has the same scope and extent a CATCH in the same place
would have (and that seems reasonable, though I'm not certain that the
condition system specifically requires that interpretation), then the handler
will be apparent to the call to ERROR, but will no longer be a valid target
(its extent was exited by the RETURN in the UNWIND-PROTECT body).
"exited" in the preceding line should be "ended" or "passed over".
This is true, but interchanging the first two lines of the example would fix it.
It is quite intentional that the MINIMAL proposal says this style of coding
is non-portable. In current practice it is non-portable.
∂13-Dec-88 1816 CL-Cleanup-mailer Issue: REST-LIST-ALLOCATION (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88 18:16:25 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508176; Tue 13-Dec-88 21:15:56 EST
Date: Tue, 13 Dec 88 21:15 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REST-LIST-ALLOCATION (Version 3)
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
In-Reply-To: <881212-161110-5531@Xerox>
Message-ID: <881213211541.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
This is a tough issue.
NEWLY-ALLOCATED and MUST-SHARE have the virtue of involving the fewest
hassles for portable code. Latent surprises of this kind are invariably
terribly hard to track down, and it's a definite feature to avoid the
problem.
On the other hand, MAY-SHARE is the clearly efficient thing for what is
probably the most common case, so we should be careful not to pick a
semantics that forces undue expense in that case.
This problem may be related to the DYNAMIC-EXTENT issue. Just as we want
the option of new structures being stack-allocated, we seem to want the
option of new structures being shared or unshared. I could imagine,
as GZ suggests, a declaration to accomodate this. For example:
(DEFUN FOO (&REST X)
(DECLARE (UNSHARED-STRUCTURE X))
...)
We might someday figure a way to generalize to other cases, such as uses
of backquote. Consider:
(LET ((X `(A ,B C)))
(DECLARE (UNSHARED-STRUCTURE X))
...)
For now, though, I think it best to consider restricting the variable to
only &REST variables (by not allowing the variable to be specified!).
This kind of declaration may sound bizarre, but I think GZ is right in
asserting that it's an important thing that portable programs must
constantly reckon with and need a serious solution for.
On the basis of the reasoning presented above, my position is that we
should do the following two things:
- Drop the NEWLY-ALLOCATED and MUST-SHARE variants as practically
infeasible and ramp up MAY-SHARE.
- Extend MAY-SHARE to include a mechanism that seriously addresses
the fact that sometimes we need to get a particular kind of
functionality. Perhaps declarations like
(REST-LIST-SHARING :NEVER)
(REST-LIST-SHARING :SOMETIMES)
(REST-LIST-SHARING :ALWAYS)
or
(REST-LIST-ALLOCATION :NEW)
(REST-LIST-ALLOCATION :UNSPECIFIC)
(REST-LIST-ALLOCATION :SHARE)
The only issue then would be whether there were implementations where
the always-share functionality would be impossible to implement (since
the never-share functionality could at least be simulated in
implementations where it couldn't be reliably detected), and whether we
were willing to allow such implementations to just signal an error in
that case. (If we were to permit implementations to not implement :SHARE,
we might be better off not offering the feature in the first place.)
∂13-Dec-88 2111 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88 21:11:04 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508226; Wed 14-Dec-88 00:10:13 EST
Date: Wed, 14 Dec 88 00:09 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
To: jonl@lucid.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8812070640.AA11552@bhopal>
Message-ID: <881214000958.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Disclaimer: The contents of this note are my personal opinion and not
necessarily the opinion of Symbolics.
Summary: I'm quite upset by this message of JonL's, not because of its
technical position, but because of the lack of personal respect
JonL has shown for my technical position. This message has some
technical content, and therefore I want it in the CL-Cleanup
archives, but its primary content is political, emotional, and
personal. As such, recipients other than JonL shouldn't treat it
as high priority reading.
-----
Date: Tue, 6 Dec 88 22:40:23 PST
From: Jon L White <jonl@lucid.com>
...
This may be the Symbolics 3600 status quo (and TI Explorer); but no other
implementation I'm aware of takes this variant view of CLtL. Considering
the strong, though not unanimous, opposition to making all arrays
adjustable, I don't see how you can expect to resolve the debate simply
making such a statement.
Status quo has, to the best of my knowledge, always been taken in our
discussions to mean "what is implemented", not "what is understood by an
elite group of people who designed CLtL in the first place". We have usually
reserved the phrase "what was intended" to refer to what people might have
had in mind, and we might debate what was intended, but as far as I'm
concerned there is never any debate on the status quo.
I discount from the status quo only obvious violations (eg, an implementation
fails to support bignums) where no defensible reading of the manual will cover.
I count for the status quo -any- implementation for which there is a passage
in CLtL which the implementors claim to have faithfully interpreted and which
they have made a financial investment in.
I did not question the validity of someone's claim that Choral had implemented
NCONC as APPEND. They claim this was a mere bug, but if they hadn't, I would
have been willing to accept it as the "status quo" (even if not "what was
intended") because they can probably find text to back it up.
If you take a different view of the status quo, you should go back to Mathis or
that nice lady who on the first day of X3J13 gave us a lesson on the legalities
of X3J13 and the dangers of claiming to be able to "interpret" CLtL. You'd
better be -very- careful not to make any public statements of the form
"Implementation X is not conforming because of ..." unless you're prepared to
cite written text (not popular myth) to back yourself up or you may find yourself
in court backing up such slanderous claims. Such, at least, was their contention,
and I'm inclined to believe they were right to warn us thus.
It is not the business of this committee to retroactively invalidate good faith
implementations of CLtL. If we want to make tougher standards, we can do so only
by making a new standard which is more rigorously defined.
Why not just admit that the intent of simple arrays was to accommodate
the needs of "stock" hardware implementations?
I admitted this already.
Thus remembered, no one could mistake the intent for SIMPLE-ARRAYs -- that
they be non-adjustable.
Not so. Our collective recollection is that you were -permitted- (not -required-)
to make them be non-adjustable.
Indeed, why create such an arbitrary type subset if it were only of
theoretical interest? [Remember also the "RPG Memorial Array" proposal.]
It isn't only of theoretical interest. It's clearly a bug that ADJUSTABLE-ARRAY-P
doesn't predicate whether ADJUST-ARRAY will work. That should just be fixed.
It's not clear that it's a bug that the effect of doing :ADJUSTABLE NIL
was not specified. There are plenty of useful applications that derive
from the interpretation we support.
Then this whole disingenuous
Excuse me, but this kind of thing really pisses me off. This adjective has no
place in any discussion of this sort and if I see it again I will disinvolve
myself with this and perhaps any further discussion.
We could not be more up front and sincere: We have said some people here believe
the wording is as it is for a reason. The reason, while not popular -- I don't
even like it personally -- is completely defensible from a technical standpoint
and not subject to any kind of common sense arguments that there was "only one
possible interpretation". There may have been only one "obvious interpretation"
but on inspection you should be willing (as am I) to agree, at least reluctantly,
that this is a valid point of view -- if for no other reason because people
whom you hopefully respect have asserted that it is a valid point of view.
In general, my rule of thumb for what is ambiguous is anything for which all
parties cannot be convinced, through discussion, is not ambiguous. This is,
if one party thinks something is ambiguous and one party thinks it is not, then
by (my) definition, it is ambiguous. The only exceptions are extreme cases where
where the individual claiming ambiguity can be demonstrated to have insufficient
command of the issue (eg, hairy floating point stuff) or insufficient command
of the English language; I assert that on this issue, I have neither of these
deficiencies, and that my claim of ambiguity is generous.
re-reading of the history of adjustable
arrays and "loopholes" in CLtL could be dropped; and Symbolics could
simply say something like:
"Symbolics extends Common Lisp ARRAY functionality in an improved,
but technically incompatible, way."
It is your burden to demonstrate that it is incompatible. I have cited
specific passages with which you might quibble about "original intent" but
you cannot quibble about "technically compatible". In point of fact, we are
within the letter of the stated rules, and we have cited reasons
I've said over and over that I don't happen to personally like the Symbolics
[Genera] interpretation (Cloe's interpretation is different :-), but I think
they/we are within their/our rights to claim it.
That simple, frank statement would make everybody much more comfortable
(especially 3600 user's who wonder why their code doesn't port), and
would finally close the debate so that we don't have to waste yet more
and more time on it.
Don't hold your breath. It's just not as simple as that. There are really major
issues of compatibility and QA that we have to deal with, and the expense for
us would probably not be small.
Besides, the Cloe development environment (which is what I and many others
here recommend for people porting code out to other environments) does offer
the interpretation you suggest.
[Yes, I'm aware that Symbolics would have to face
persistent demands from some of their users to "come into compliance";
but it's much more likely that you can make satisfactory explanations to
these customers than that you can convince the "stock hardware" types to
swallow universal adjustability.]
I don't see why either of these extremes is necessary. I'm not advocating
that stock hardware swallow universal adjustability and I'm asking them not
to force this change on us.
Virtually every other vendor has at one time or another indicated that some
proposed change would be prohibitively expensive. We have generally treated
such claims with respect. Rarely has anyone had the gall to suggest that they
should just bite the bullet and accept an enormous incompatible change or
"just declare themselves to be incompatible" (a dangerous trend). In general,
such proposals have stopped dead in their tracks until/unless someone could
propose a serious way around the difficulty -- and "just declare yourself to
be incompatible" has never been an avenue open to us before. I am awestruck
that you could suggest this.
If you want to disagree with our proposal on technical grounds, that's fine.
But keep in mind that compatibility with existing code, transition cost, etc.
are legitimate concerns applied in every other proposal writeup and we're
fully entitled to assert that this is a proposal of major cost to us.
I think, too, we're within our rights to ask for a little respect from the
other members of CL-Cleanup when we assert such a position.
I personally would like to see the tighter definition you'd like to see,
but given the potential expenses involved, I see nothing disingenuous
about my having described the status quo as I did, and nothing
unreasonable about my having suggested that this is our only viable
alternative.
∂13-Dec-88 2201 CL-Cleanup-mailer Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88 22:01:18 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508246; Wed 14-Dec-88 01:00:33 EST
Date: Wed, 14 Dec 88 01:00 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <881205-121523-3921@Xerox>
Message-ID: <881214010015.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 5 Dec 88 12:14 PST
From: masinter.pa@Xerox.COM
...
What does it mean to CLOSE a composite stream ( broadcast two-way
synonym
concatenated) ? The choices I can think of are:
a) no effect
b) implementation dependent (ugh)
c) closes constituent streams
d) the composite stream is "closed" (no I/O operations allowed) but
the constituents are not.
I prefer c.
There is another possibility:
e) signals an error
I can't think of any reason why a Common Lisp program ever needs to call
CLOSE on a composite stream. Can someone suggest a legitimate case where
you wouldn't instead close the underlying stream?
My preferences are, in order of diminishing preference:
(e) is my preference unless someone cites a screw case.
(c) seems certainly justifiable. it -could- be an incompatible change for
some implementations, i suppose. it makes more sense for things like
broadcast streams (which are usually non-interactive) than it does
for echo streams (which are sometimes interactive). Anything which
might accidentally get mixed up with the terminal makes me nervous.
I agree one shouldn't close terminal streams on purpose -- what I'm
worried about is someone accidentally closing a terminal stream because
of some indirection through a composite stream.
(d) is weird. i can't figure out what i think of it. it seems
counterintuitive and yet it probably wouldn't be harmful if it were
well-defined that this was what it did.
(b) is the status quo, and technically requires no action though a
clarification wouldn't bother me. making things explicit is often
a good idea.
(a) is neither the status quo nor does it sound very desirable to me.
if there were any place where this was desirable in some non-trivial
application, i'd be curious to hear about it.
What does it mean to close a constructed stream (e.g., STRING)?
a) no effect
b) implementation dependent (ugh)
c) the constructed stream is "closed" (no I/O operations allowed).
I prefer a or c.
I don't care which of (a) or (c) as long as it's clearly documented.
(c) would be more consistent with good programming hygeine, though might
have some [probably trivial] storage and/or execution efficiency impact
in some implementations.
(b) is the status quo, and technically requires no action though a
clarification wouldn't bother me. making things explicit is often
a good idea.
∂13-Dec-88 2207 CL-Cleanup-mailer Re: Issue ALIST-NIL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88 22:07:44 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508251; Wed 14-Dec-88 01:07:03 EST
Date: Wed, 14 Dec 88 01:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue ALIST-NIL
To: masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, IIM@ECLA.USC.EDU
In-Reply-To: <881202-163852-131@Xerox>
Message-ID: <881214010647.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 2 Dec 88 16:36 PST
From: masinter.pa@Xerox.COM
... Unless I hear otherwise (and I'll leave this open for Kent, who is on
vacation until December 10 and may not read this until much later), I will
mark this as Withdrawn.
Agreed: withdrawn in favor of the suggested editorial advice.
∂13-Dec-88 2215 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Dec 88 22:15:52 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA06918g; Tue, 13 Dec 88 22:13:07 PST
Received: by bhopal id AA11940g; Tue, 13 Dec 88 22:15:07 PST
Date: Tue, 13 Dec 88 22:15:07 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812140615.AA11940@bhopal>
To: masinter.pa@Xerox.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 8 Dec 88 23:21 PST <881208-232139-5495@Xerox>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
re: I'll add that I still prefer the proposal I outlined (awkwardly) in
November 1987, which was neither explicitly-vague or explicitly-defined.
The "sequence" functions:
NREVERSE DELETE DELETE-IF DELETE-IF-NOT DELETE-DUPLICATES NSUBSTITUTE
NSUBSTITUTE-IF NSUBSTITUTE-IF-NOT
and the destructive set manipulation functions:
NUNION NINTERSECTION NSET-EXCLUSIVE-OR
should be explicitly-vague, but the others
SETF of GETF, REMF, SETF of GET, REMPROP, NCONC, NRECONC, NBUTLAST,
NSUBST, NSUBST-IF, NSUBST-IF-NOT
should be specified.
I think I prefer your version too, for essentially the reasons you
elucidated further in your msg.
-- JonL --
∂13-Dec-88 2241 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Dec 88 22:41:23 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA06973g; Tue, 13 Dec 88 22:37:36 PST
Received: by bhopal id AA11971g; Tue, 13 Dec 88 22:39:35 PST
Date: Tue, 13 Dec 88 22:39:35 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812140639.AA11971@bhopal>
To: Gregor.pa@Xerox.COM
Cc: masinter.pa@Xerox.COM, pierson@mist.encore.com, Gray@DSG.csc.ti.com,
cl-cleanup@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Sun, 11 Dec 88 10:45 PST <19881211184511.8.GREGOR@PORTNOY.parc.xerox.com>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
re:
My "compromise" proposal, that Gray seemed to agree to, was to insist
that implementations which "hook" their REQUIRE into some kind of
DEFSYSTEM -- as an implementation- specific extension -- must also
provide a special variable flag that disengages any such "hook-up".
While it is true that many people will persist in writing non-portable
code, the portable use of REQUIRE to ensure that required package
definitions are "already loaded in" is of paramount importance. There
is no other portable feature to help ensure that.
I don't buy this. You can do it portably with find-package and intern.
You might claim that is gross, but I don't believe it. . . .
The point underlying this claim has been re-iterated several times during
the discussion of this issue, but let me try again.
-- a REQUIRE used in an implementation that can hook into a defsystem
will trigger that loading. There is no portable way to do so now
[doesn't matter that the hook merely errors out for implementations
that don't have a defsystem, or for which the user failed to supply
the appropriate database]. REQUIREs which supply explicit filenames
are not portable -- that's precisely how this proposal got started.
-- any REQUIRE is expression of intent on the part of the programmer.
REQUIREs are in common usage around the community, and they are
especially useful in package "requirements". All such expressions
are portable.
But I have no idea what you mean by suggesting that these usages of
REQUIRE can be replaced by some idiosyncratic usage of FIND-PACKAGE etc.
Incidentally, the point about "expression of intent" was said much
better by Larry last October:
Date: 18 Oct 88 14:13 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
The thing that distinguishes PROVIDE and REQUIRE from their obvious
implementations is that they have declarative rather than operative
semantics. Program walkers, DEFSYSTEM constructors as well as compilers
might be expected to pay special heed to PROVIDE and REQUIRE, but not pay
any special heed to direct manipulation of *MODULES*.
We should be careful in the standard to distinguish between what things
mean and how they may be implemented, but doubly so in the case of macros
and special forms that may get processed at times other than EVAL-time.
-- JonL --
∂14-Dec-88 0007 CL-Cleanup-mailer Issue: TAILP-NIL (Version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Dec 88 00:06:56 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA07168g; Wed, 14 Dec 88 00:03:21 PST
Received: by bhopal id AA12044g; Wed, 14 Dec 88 00:05:20 PST
Date: Wed, 14 Dec 88 00:05:20 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812140805.AA12044@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: barmar@Think.COM, cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: David A. Moon's message of Tue, 13 Dec 88 11:52 EST <19881213165206.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)
re: . . . (EQ is only
in Common Lisp as a concession to implementors who haven't figured out
how to implement EQL efficiently (it isn't hard), or hadn't figured it
out yet in 1984).
Hmmm, I may remember something similar said in the late 1960's or very
early 1970's about why EQ was still in the language -- but back then,
the contender was EQUAL rather than EQL. Plus ca change . . . maybe
there is a more fundamental reason than incompotent implementors. Like,
maybe some folks implement their memory management systems in Lisp, and
are reluctant to give up all user-accessibility to this historic, object
identity function?
But that's just a conjecture. I really don't know why (and don't
particularly care why) EQ persists.
-- JonL --
∂14-Dec-88 0019 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Dec 88 00:19:33 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA07199g; Wed, 14 Dec 88 00:16:48 PST
Received: by bhopal id AA12063g; Wed, 14 Dec 88 00:18:48 PST
Date: Wed, 14 Dec 88 00:18:48 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812140818.AA12063@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 9 Dec 88 16:47 PST <881209-164733-1437@Xerox>
Subject: Issue: COERCE-INCOMPLETE (Version 2)
Wasn't there some hairy issue with ...-FUNCTION-... in it's name that
we discussed verbally at the June meeting? and didn't we take a vote
there to ammend that issue by saying that
(COERCE '(LAMBDA ...) 'FUNCTION)
would be the way to go from list structure to a "real" function?
That didn't seem to be in your list of obvious candidates for COERCE
extension.
-- JonL --
∂14-Dec-88 0143 CL-Cleanup-mailer Issue: DEFPACKAGE (Version 7)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Dec 88 01:43:09 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA07351g; Wed, 14 Dec 88 01:40:25 PST
Received: by bhopal id AA12144g; Wed, 14 Dec 88 01:42:24 PST
Date: Wed, 14 Dec 88 01:42:24 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812140942.AA12144@bhopal>
To: barmar@Think.COM
Cc: CL-CLEANUP@sail.stanford.edu
In-Reply-To: barmar@Think.COM's message of Sat, 10 Dec 88 15:57:29 EST <8812102057.AA18056@kulla.think.com>
Subject: Issue: DEFPACKAGE (Version 7)
re: . . . How about this as an
alternative to "at most the original package will be updated":
"however, no objects other than the original package will be
modified as a result."
Doesn't work -- by performing the newer definition, you may require links
to be modified in other packages' used-by lists.
If this really is an insoluable problem for you, and if other people
also feel so uncomfortable with it, then maybe we should just flush
the whole phrase; after all, the primary things we want to say are that:
(1) you don't change the name-to-package mapping, and
(2) you *might* alter the existing package [then again, you might not].
re: . . . Kathy's proposal for
the new classification system of error situations includes a
description of this case. As I said, I don't remember the actual
terminology she used for this case (I suggested "undefined but
benign", but she rejected it), but the description was like what you
described.
Hmmm, well I'm not familiar with this yet newer error terminology proposal.
-- JonL --
∂14-Dec-88 0208 CL-Cleanup-mailer Please add me to the cl-cleanup mailing list
Received: from RELAY.CS.NET (GW1.CS.NET) by SAIL.Stanford.EDU with TCP; 14 Dec 88 02:08:14 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac00167; 14 Dec 88 4:55 EST
Received: from etl.jp by RELAY.CS.NET id ac03458; 14 Dec 88 4:49 EST
Received: by etlcom.etl.junet (3.2/6.3Junet-1.0)
id AA02955; Wed, 14 Dec 88 13:25:06 JST
Date: Wed, 14 Dec 88 13:25:06 JST
From: Haruyuki Kawabe <kawabe@etl.jp>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Please add me to the cl-cleanup mailing list
Please add mlist%unisys.junet@uunet.uu.net to the cl-cleanup mailing list.
Thanks in advance.
Haruyuki Kawabe
Knowledge Systems
Nihon Unisys, Ltd.
2-17-51 Akasaka, Minato-ku,
Tokyo 107, JAPAN
e-mail: kawabe%etl.jp@relay.cs.net
∂14-Dec-88 1037 CL-Cleanup-mailer Issue: TAILP-NIL (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Dec 88 10:37:26 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508548; Wed 14-Dec-88 13:35:49 EST
Date: Wed, 14 Dec 88 13:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)
To: Jon L White <jonl@lucid.com>
cc: barmar@Think.COM, cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: <8812140805.AA12044@bhopal>
Message-ID: <19881214183553.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 14 Dec 88 00:05:20 PST
From: Jon L White <jonl@lucid.com>
re: . . . (EQ is only
in Common Lisp as a concession to implementors who haven't figured out
how to implement EQL efficiently (it isn't hard), or hadn't figured it
out yet in 1984).
Hmmm, I may remember something similar said in the late 1960's or very
early 1970's about why EQ was still in the language -- but back then,
the contender was EQUAL rather than EQL. Plus ca change . . . maybe
there is a more fundamental reason than incompotent implementors.
Just to clarify what I meant, since as usual I didn't express myself
very clearly in the initial message: I think of EQL as the
implementation-independent version of EQ. The behavior of EQ is
different from EQL only in implementation-dependent situations that
portable programs are not supposed to depend on. This is very different
from EQUAL, which is a semantically different operation in a way that
is meaningful across all implementations.
Like,
maybe some folks implement their memory management systems in Lisp, and
are reluctant to give up all user-accessibility to this historic, object
identity function?
Could be. But I claim that EQ has no portable meaning distinct from EQL,
only an implementation-dependent meaning, so that indeed we should be speaking
in terms of "reluctance" rather than "semantics".
Anyway, that's more than enough time on that side-issue.
∂14-Dec-88 1157 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 6)
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 14 Dec 88 11:56:23 PST
Received: by goldhill.com; Wed, 14 Dec 88 14:55:55 EST
Date: Wed, 14 Dec 88 14:55:55 EST
From: rpk@goldhill.com (Robert Krajewski)
Message-Id: <8812141955.AA16807@goldhill.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 12 Dec 88 13:44 PST <881212-134536-5049@Xerox>
Subject: Issue: PACKAGE-CLUTTER (Version 6)
I just noticed two problems in this paragraph:
A valid implimentation may have or put additional properties
on symbols (even user created symbols) as long as the
property indicators are not in the LISP, KEYWORD or USER
package.
1. The spelling of the third word.
2. It should be OK for an implementation to use property list indicators
that are *internal* symbols in the LISP package. (Of course, the ``internal''
concept doesn't make sense, really, for keywords, and internal USER symbols
are the most common kind.)
∂15-Dec-88 1315 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88 13:15:16 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00434g; Thu, 15 Dec 88 13:11:36 PST
Received: by bhopal id AA19775g; Thu, 15 Dec 88 13:13:34 PST
Date: Thu, 15 Dec 88 13:13:34 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812152113.AA19775@bhopal>
To: pierson@mist.encore.com
Cc: IIM@ECLA.USC.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Dan L. Pierson's message of Mon, 12 Dec 88 11:34:39 EST <8812121634.AA10750@mist.>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
re: In both cases, the status quo
allows careful programmers to write portable code as in:
- Never adjust a "non-adjustable" array
- Never use REQUIRE in a context that would cause file loading
The, quite legitimate, objection to the status quo is that it makes it
_very_ likely that programmers, being human and fallible, will
accidently wind up producing non-portable code because the current
versions of these features lack adaquate (read any) portable error
checking.
The problem with the Symbolics implementation (as conveyed to us by
those inside symbolics) is that there is *** no place available ***
in an array to remember the :adjustable option. Hence it is not a
trivial option for them to accommodate to the "Lucid status quo".
However, the "compromise" proposal for REQUIRE would expose a global
variable to make inhibition of vendor-specific extensions possible.
This would be trivial in anybody's implementation.
-- JonL --
∂15-Dec-88 1358 CL-Cleanup-mailer Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88 13:58:42 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00508g; Thu, 15 Dec 88 13:55:44 PST
Received: by bhopal id AA19863g; Thu, 15 Dec 88 13:57:41 PST
Date: Thu, 15 Dec 88 13:57:41 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812152157.AA19863@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 12 Dec 88 11:50 PST <881212-115107-4697@Xerox>
Subject: Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY)
re: I did see a piece of a message from Jeff Dalton included in your response
to him, but I'm missing his original message. I presume that they were not
mailed to cl-cleanup.
Both of Jeff's comments were CC'd to cl-cleanup. Since you included Moon's
negative comments in the mailing to x3j13, shouldn't Jeff's comments be
included too?
Date: Thu, 17 Nov 88 17:17:09 GMT
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: HASH-TABLE-STABILITY (version 1)
To: Jon L White <@sail.stanford.edu:jonl@lucid.com>,
cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Mon, 14 Nov 88 23:14:43 PST
Well said. I can think of one "problem": you have specified the
constraints relating the :test and the key transformation so well
that it no longer seems reasonable that users are not able to provide
their own :test and key transformation.
-- Jeff
Date: Sat, 19 Nov 88 21:35:47 GMT
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: HASH-TABLE-STABILITY (version 1)
To: jonl <@sail.stanford.edu:jonl@lucid.com>, cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Fri, 18 Nov 88 15:19:52 PST
> re: Well said. I can think of one "problem": you have specified the
> constraints relating the :test and the key transformation so well
> that it no longer seems reasonable that users are not able to provide
> their own :test and key transformation.
>
> That would be superb, if Joe Random User were able to understand this
> "clarification". I agree that that may be the only thing lacking for
> fully extensible hash-tables.
There are many things in Lisp that users may not understand initially
and so may get wrong. I don't think that's necessarily a good reason
to keep something out of the language. (And if it were, there are
parts of CLOS, SETF, and packages that we would want clean out.)
BTW, Pop11 allows user-specified test and hash (key transform)
functions.
-- Jeff
∂15-Dec-88 1444 CL-Cleanup-mailer Issue: PACKAGE-DELETION (Version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88 14:40:09 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00550g; Thu, 15 Dec 88 14:37:16 PST
Received: by bhopal id AA19979g; Thu, 15 Dec 88 14:39:13 PST
Date: Thu, 15 Dec 88 14:39:13 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812152239.AA19979@bhopal>
To: alarson@src.honeywell.com
Cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: Aaron Larson's message of Tue, 13 Dec 88 17:06:12 CST <8812132306.AA11821@pavo.src.honeywell.com>
Subject: Issue: PACKAGE-DELETION (Version 5)
re: ....
If the designated package is used by other packages, a correctable
error is signalled. ...
"continuable error"
Yes, "continuable". If there is to be another version, it can be changed.
re: After this operation completes, the contents of the symbol-package
slot of any symbol homed in the deleted package is unspecified; ...
symbol S homed in pkg P == (eq P (symbol-package S)) ?
A symbol's "home" package is defined to be the contents of its
symbol-package cell. See CLtL p.175 (about middle of page).
-- JonL --
∂15-Dec-88 1515 CL-Cleanup-mailer Issue: PACKAGE-DELETION (Version 5)
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 15 Dec 88 15:15:17 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM
by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88)
id AA25319; Thu, 15 Dec 88 17:14:00 CST
Posted-Date: Thu, 15 Dec 88 17:12:20 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA16934; Thu, 15 Dec 88 17:12:20 CST
Date: Thu, 15 Dec 88 17:12:20 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8812152312.AA16934@pavo.src.honeywell.com>
To: jonl@lucid.com
Cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: Jon L White's message of Thu, 15 Dec 88 14:39:13 PST <8812152239.AA19979@bhopal>
Subject: Issue: PACKAGE-DELETION (Version 5)
Posted-Date: Thu, 15 Dec 88 14:39:13 PST
Date: Thu, 15 Dec 88 14:39:13 PST
From: Jon L White <jonl@lucid.com>
re: After this operation completes, the contents of the symbol-package
slot of any symbol homed in the deleted package is unspecified; ...
symbol S homed in pkg P == (eq P (symbol-package S)) ?
A symbol's "home" package is defined to be the contents of its
symbol-package cell. See CLtL p.175 (about middle of page).
I guess I should have been more carefull in my statement. The problem I
was raising is that being "homed" is a satement about the symbol-package of
a symbol (and the fact that "homed" is slang), and stating that
(symbol-package x) being the deleted package and being undefined is
contradictory. The fact that you are stating something about the (previous)
state of the symbol-packge, and that kill-package may (or may not) change
the symbol-package was being muddled. In retrospect it was undoubtedly
obvious to everybody what the statement meant.
∂15-Dec-88 2136 CL-Cleanup-mailer Issue: TAILP-NIL (Version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88 21:36:13 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00886g; Thu, 15 Dec 88 21:33:11 PST
Received: by bhopal id AA20798g; Thu, 15 Dec 88 21:35:11 PST
Date: Thu, 15 Dec 88 21:35:11 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812160535.AA20798@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Tue, 13 Dec 88 19:05 EST <881213190509.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)
re: I, for one, have found that nearly every time I think LDIFF would
suffice, the EQL test (rather than EQUAL), and its failure to take
a test argument, has screwed me -- causing me to do what I have always
felt is needless rewrite. I have only rarely needed TAILP and I can't
remember if I ended up actually using it or not -- I'd suspect that
the constraints on it make it next to useless.
This paragraph provides proof in substance of one of the reasons for
wanting to toss out TAILP, namely
(1) the "test" questions is at least as complex as for defining
EQUAL -- and we never did come to agreement about that;
It would only be sheer conjecture that the currently unused TAILP
would become generally useful if it were extended to take a :test
argument. By the reasoning in your note, you don't believe we have
any way to evaluate this kind of question; you say:
``. . . we have no way of evaluating what it
means for the operator to be "used a lot"''
-- JonL --
∂15-Dec-88 2203 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88 22:03:41 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00902g; Thu, 15 Dec 88 22:00:41 PST
Received: by bhopal id AA20824g; Thu, 15 Dec 88 22:02:42 PST
Date: Thu, 15 Dec 88 22:02:42 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812160602.AA20824@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 13 Dec 88 20:59 EST <19881214015936.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT (Version 5)
I wanted to recommend against accepting this proposal in its current
format; it looked like to me that a lot more work was needed to make
it both accurate and comprehensible. Since I don't have the time to
work one it before the January meeting, I won't be able to explain
my objections in much better detail (without, in fact, going to the
trouble to prepare the necessary revised proposal, which I don't
have time to do!)
What would you like to see happen? If you think you can do it in time
before the January meeting, could you _please_ make the revision, and
mail that out? to X3J13 as well?
-- JonL --
∂16-Dec-88 0108 CL-Cleanup-mailer Really about the ontology of EQ {Issue: TAILP-NIL (Version 5)}
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Dec 88 01:07:55 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00962g; Fri, 16 Dec 88 01:04:33 PST
Received: by bhopal id AA20981g; Fri, 16 Dec 88 01:06:32 PST
Date: Fri, 16 Dec 88 01:06:32 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812160906.AA20981@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: barmar@Think.COM, cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: David A. Moon's message of Wed, 14 Dec 88 13:35 EST <19881214183553.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Really about the ontology of EQ {Issue: TAILP-NIL (Version 5)}
re: Just to clarify what I meant, since as usual I didn't express myself ...
Well me too (i.e. I wasn't as clear as possible). [Incidentally,
although this topic is only remotely connected to TAILP-NIL, it
seems to be central the to abortive attempt to "clean up" the
EQUAL predicate. Hence, I drone on some more. ...]
The issue "way back when" wasn't whether EQUAL would be portable and EQ
not portable (since "pdlnums" hadn't even been thought of then), but
rather whether or not a programmer should be allowed to find out if two
"equivalent" pieces of data are stored in the same location. The Lisp
1.5 definition of EQ was "EQUAL, on atoms (meaning, symbols)". I suppose
the explanations about "update semantics" forced the hand of those who
wanted to flush EQ back then. That is, an EQUAL but non-EQ copy of a cons
cell wouldn't show the results of updates applied to the original cell.
This kind of analysis is probably more interesting to a pure functional
programming type, or to a data-flow type person.
Now, as the the EQ/EQL purpose: Interlisp used to have a function called
SETN, which would actually modify the contents of a number "box" --
thus it made sense for Interlisp to have both EQ and EQL (it was called
EQP in Interlisp), to be able to choose whether such updates are to be
considered important. Of course, Common Lisp has no updators for numbers
or characters -- only new constructors (which is why SETF of LDB is so
complicated) -- so the only conceivable use now for distinguishing EQ
and EQL is explicit storage management.
(setq pi 3.14159265) ==> 3.14159265
pi ==> 3.14159265
(setq saved-pi pi) ==> 3.14159265
;; the "Tennessee Patch", in Interlisp-10 code
(setn pi 3.0) ==> 3.0
pi ==> 3.0
(eq pi saved-pi) ==> T
-- JonL --
∂16-Dec-88 0838 CL-Cleanup-mailer EQ
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 16 Dec 88 08:37:45 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa19006; 16 Dec 88 10:56 EST
Received: from draper.com by RELAY.CS.NET id ad00211; 16 Dec 88 10:49 EST
Date: Fri, 16 Dec 88 07:59 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: EQ
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
re: The only purpose for retaining EQ as opposed to EQL is storage management,
or words to that effect...
The basic reason for the existence of EQ, as I see it, is to compare interned
symbols. LISP is a symbol processing language primarily because the comparison
of non-arithmetic quantities is optimized by insuring that the expensive part
is done at symbol creation time (i.e. interning) and all subsequent tests are
very fast (address comparisons). Now, it is true that EQL on symbols is the
same as EQ, so EQ per se is unnecessary. But isn't it preferable to retain EQ
so that the compiler can generate the very fast inline operation for EQ instead
of (possibly, depending on the implementation) having to invoke an out-of-line
routine or a longer sequence of inline code to compare two things using EQL?
If neither operand is a constant or a type-declared variable or function call,
it is not known whether the EQL call may be optimized into an EQ call. (This
is probably not a problem for your implementation, JonL, or for many others',
but it may be for others - it is for mine.)
∂16-Dec-88 1101 CL-Cleanup-mailer Really about the ontology of EQ {Issue: TAILP-NIL (Version 5)}
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Dec 88 11:01:45 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01270g; Fri, 16 Dec 88 10:55:17 PST
Received: by bhopal id AA21626g; Fri, 16 Dec 88 10:57:15 PST
Date: Fri, 16 Dec 88 10:57:15 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8812161857.AA21626@bhopal>
To: jonl@lucid.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, barmar@Think.COM,
cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: Jon L White's message of Fri, 16 Dec 88 01:06:32 PST <8812160906.AA20981@bhopal>
Subject: Really about the ontology of EQ {Issue: TAILP-NIL (Version 5)}
;; the "Tennessee Patch", in Interlisp-10 code
(setn pi 3.0) ==> 3.0
I thought it was Indiana that passed that law.
jlm
∂17-Dec-88 0118 CL-Cleanup-mailer EQ
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Dec 88 01:18:15 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01901g; Sat, 17 Dec 88 01:15:22 PST
Received: by bhopal id AA23281g; Sat, 17 Dec 88 01:17:22 PST
Date: Sat, 17 Dec 88 01:17:22 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812170917.AA23281@bhopal>
To: SEB1525@draper.com
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: "Steve Bacher (Batchman)"'s message of Fri, 16 Dec 88 07:59 EST <8812161638.AA01151@lucid.com>
Subject: EQ
re: If neither operand is a constant or a type-declared variable or function
call, it is not known whether the EQL call may be optimized into an EQ
call. (This is probably not a problem for your implementation, JonL, or
for many others', but it may be for others - it is for mine.)
I think that's a universal problem, but not a particularly serious one.
Of course, Lucid's Production-Quality compiler makes all the obvious type
optimizations; but for EQL, it also does an in-line check for EQ success
before calling EQL out-of-line. (Vax/NIL used to do a bit more on EQUAL,
based on monitoring some MACSYMA code; but that was before EQL came about).
I have often referred to these kinds of tricks as "beating out the function
call" -- namely, a fast, in-line, fail-safe, but not complete test which is
performed just before taking the time to go out-of-line. I think Richard
Fateman of UCB independently discovered "beating out the function call" on
EQUAL -- for exactly the same reason (tuning the performance of Vaxima).
Internally, Lucid code ocasionally makes use of (optimizable) functions
named EQ-FOR-EQL-P and EQ-FOR-EQUAL-P; typically they are used to select
one of two alternative methods; e.g., ASSOC can dynamically turn into
ASSQ. These checks "open compile". So the time to make the determination
pays off immensely in the one case by reducing out-of-line calls, and in
the other case, the out-of-line calls are so costly that the check time
is negligible. It wouldn't matter whether or not EQ were part of the
portable standard -- these tricks would still be applicable to the way in
which the system internals and compiler output work.
A good point to make for retention of EQ is that even though portable
code may not be able to utilize the difference between EQ and EQL, it
will still be the case that every implementation will have *some*
function that does address/pointer identity comparison; so we might as
well all call it the same thing, so as to minimize the culture shock when
moving from one implementation to another.
-- JonL --
∂17-Dec-88 1338 CL-Cleanup-mailer Re: EQ
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 17 Dec 88 13:37:59 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa04738; 17 Dec 88 19:10 GMT
Date: Sat, 17 Dec 88 19:23:01 GMT
Message-Id: <9194.8812171923@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: EQ
To: Jon L White <@sail.stanford.edu:jonl@lucid.com>,
SEB1525%draper.com@NSS.Cs.Ucl.AC.UK
In-Reply-To: Jon L White's message of Sat, 17 Dec 88 01:17:22 PST
Cc: cl-cleanup@sail.stanford.edu
> A good point to make for retention of EQ is that even though portable
> code may not be able to utilize the difference between EQ and EQL, it
> will still be the case that every implementation will have *some*
> function that does address/pointer identity comparison; so we might as
> well all call it the same thing, so as to minimize the culture shock when
> moving from one implementation to another.
Just so. While portable code is more important, I don't think we should
discount non-protable code completely. And I don't think we should force
people to write only portable code. Besides, using EQ in a portable way
is generally easier than using declarations.
I realize that CL has gone a different way with the generic arithmetic
functions, but the two cases are not identical. If necessary, I suppose
a more elaborate justification for EQ could be attempted, but is there any
great harm to keeping EQ?
∂20-Dec-88 1710 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Dec 88 17:09:53 PST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 510806; 20 Dec 88 20:08:36 EST
Date: Tue, 20 Dec 88 20:14 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT (Version 5)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8812160602.AA20824@bhopal>
Message-ID: <19881221011406.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Thu, 15 Dec 88 22:02:42 PST
From: Jon L White <jonl@lucid.com>
I wanted to recommend against accepting this proposal in its current
format; it looked like to me that a lot more work was needed to make
it both accurate and comprehensible.
I agree with that for version 5. I'm not sure whether I agree with that
for the earlier versions, I would have to go back and re-read them.
Since I don't have the time to
work on it before the January meeting, I won't be able to explain
my objections in much better detail (without, in fact, going to the
trouble to prepare the necessary revised proposal, which I don't
have time to do!)
What would you like to see happen? If you think you can do it in time
before the January meeting, could you _please_ make the revision, and
mail that out? to X3J13 as well?
I'd help if I could, but I cannot revise the proposal in its current
two-proposal form, because I cannot think of any coherent, unambiguous,
implementation-independent way to say what I think the second proposal is
trying to say. At this point it wouldn't surprise me if it turns out to be
impossible to specify it in any acceptable way. If someone else can come
up with it, fine, I'd love to be proved wrong.
If that doesn't happen, I'd like to see either the first proposal (the one
that ends the dynamic extent of an exit sooner) accepted or retain the
status quo. I think the status quo, which is vague, ambiguous, and
incoherent, would still be better than adopting a new proposal that (I
feel) is still ambiguous and incoherent, and at the same time is
incompatible with current practice. As I commented earlier, I think
version 5 of the second proposal (the one that ends the dynamic extent of
an exit later) is in fact incompatible with all current implementations,
and may not be implementable at all. I don't think that was what was
intended, but even what was probably intended is incompatible with some
current implementations (Genera is the one I know about).
∂22-Dec-88 1127 CL-Cleanup-mailer Issue: LISP-PACKAGE-NAME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Dec 88 11:27:34 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 511418; Thu 22-Dec-88 14:03:31 EST
Date: Thu, 22 Dec 88 14:03 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-PACKAGE-NAME (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881222140316.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: LISP-PACKAGE-NAME
References: 11.6 Built-in Packages (pp181-182)
Category: CHANGE
Edit history: 22-Dec-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Since ANSI Common Lisp will differ from the Common Lisp described by CLtL,
it will not be possible to have support for both in the same Lisp image
if ANSI Common Lisp insists on placing its functionality in the package
named LISP.
Further, use of the name unqualified name LISP by the ANSI Common Lisp
community is inconsistent with ANSI's expressed position to ISO that
the term "LISP" names a language family rather than a specific dialect
within that family.
Proposal (LISP-PACKAGE-NAME:COMMON-LISP):
Define that ANSI Common Lisp uses the package name COMMON-LISP, not LISP.
Define that the COMMON-LISP package has nickname CL.
Since some symbols (e.g., T, NIL, and LAMBDA) might have to be shared
between COMMON-LISP and LISP in implementations simultaneously supporting
both, clarify that the initial symbols specified by ANSI Common Lisp as
belonging in the COMMON-LISP package need not have a home package of
Common-Lisp.
Test Case:
In an implementation supporting CLtL's LISP package and
the ANSI Common Lisp CL package proposed here:
(EQ 'LISP:T 'CL:T)
=> not specified, due to this proposal, but probably T
(EQ 'LISP:CAR 'CL:CAR)
=> not specified, due to this proposal, but probably T
(EQ 'LISP:FUNCTIONP 'CL:FUNCTIONP)
=> not specified, due to this proposal, but since FUNCTIONP is
changed incompatibly between CLtL (LISP) and CL (ANSI), there
are good reasons why this might return NIL.
(SYMBOL-PACKAGE 'CL:T)
=> not specified, due to this proposal. Perhaps #<Package CL>,
perhaps #<Package LISP>, or perhaps something implementation-specific.
(SYMBOL-PACKAGE 'LISP:T)
=> not specified, not due to this proposal, but because CLtL didn't
specify this explicitly.
Rationale:
In practice, some implementations will have very legitimate reasons for
wanting to Lisp dialects to be coresident. As it stands, they will have
little other choice than to make the two use different packages, and so
will be forced to be incompatible with one or the other dialect unless
we choose a different package name for the one dialect for which there
is currently no existing code.
Not only is this important the CLtL and ANSI Common Lisp communities, but
also, if we continue to use the name LISP, it sends a signal to the ISO
Lisp community that the "latest and greatest" Lisp should use the generic
name LISP, and they may try to use it as well. If ISO Lisp turns out to
be very different than ANSI Common Lisp, there may be motivation down the
line for having ISO Lisp and ANSI Common Lisp co-resident, and conflicts
will inevitably arise if both want to use the name LISP. This will almost
certainly lead to a confrontation where one Lisp dialect tries to force
the other out by the artificial means of asserting its right to this
generic name. Choosing a name which compatibly admits the option of
introducing other dialects into the environment at a later date without
conflict is a good way to avoid a class of potential problems.
Although there are a few problems which could come up due to the symbol
package of initial symbols being unspecified, experience with
implementations that do this suggests that they are very few.
Problems occur only in the rare circumstance that all of the following
conditions are met:
- A symbol S on the LISP package but with home package H (that is not "LISP")
is shadowed in some package P of implementation A.
- A program F in package P uses the shadowed symbol H:S by an explicit
LISP: or H: package qualification. (Only the case of using "LISP:" is
interesting, of course, since if H were named explicitly, we would be
outside the bounds of portable code).
- The program F, referring to H:S, is printed out in implementation A
while using package P (or some other package that shadows S, so that
the H package qualifier appears explicitly) and an attempt is made to
re-read it in implementation B.
- Implementation B has no package named H, has a package named H but no
external symbol named S, or has a package named H with external symbol
S but the symbol H:S has different semantics in implementation B than
it did in implementation A.
In practice, this hardly ever happens. It would happen even less if
programmers were explicitly alerted that it was a potential problem they
needed to guard against.
Current Practice:
Symbolics Genera already has a package named COMMON-LISP with nicknames
CL and LISP. As such, this would be an incompatible change for Genera.
Cost to Implementors:
Small.
In some cases, this may even have `negative cost' because it will provide
implementors a way of avoiding incompatible changes to released operators.
Cost to Users:
Small.
In some cases, this may even have `negative cost' because existing code
would be able to continue to run in implementations which chose to support
both CLtL's LISP and ANSI Common Lisp's CL packages, thereby allowing
developers to put off a massover changeover, perhaps doing the transition
more incrementally.
Cost of Non-Adoption:
Implementations trying to support multiple dialects in the same environment
would be forced to violate one or the other spec.
Worse, different implementations faced with the same set of hard choices
about which spec to violate in order to concurrently support two dialects
might not make the same choices, leading to even more gratuitous
incompatibility.
ANSI's position in ISO that we are not trying to legislate the meaning of
-the- LISP dialect would be weakened.
Benefits:
Needless incompatibility would be avoided in a variety of situations.
Aesthetics:
Failing to specify the home package of symbols in the LISP and CL packages
seems unaesthetic because it appears to diminish print/read invertability,
but as observed above, that case is rare.
Failiing to specify a way in which lisp dialects can be co-resident is also
unaesthetic because in practice implementors with a need to do this will do
so whether the standard allows them or not, and it will be a source of
severe divergence among implementations.
Discussion:
Symbolics Genera offers two co-resident dialects of Lisp: Zetalisp and
Symbolics Common Lisp. The Symbolics Cloe development environment adds
a third co-resident dialect, making an environment in which two differing
Common Lisp dialects (Symbolics Common Lisp and Cloe) must cooperate.
Already in Cloe it is not possible for the home package to contain
package "LISP" since Cloe's concept of what the "LISP" package is differs
from Genera's concept of what the "LISP" package is, yet they are forced
by efficiency constraints to share the same symbol. It is Pitman's belief,
based on extensive experience with Cloe, that failure to pass this proposal
(or something very like it) will lead to all sorts of trouble for Common
Lisp users and implementors down the road.
Pitman strongly supports this proposal.
∂22-Dec-88 1350 CL-Cleanup-mailer Re: Issue: LISP-PACKAGE-NAME (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 22 Dec 88 13:49:53 PST
Received: by ti.com id AA09673; Thu, 22 Dec 88 15:48:59 CST
Received: from Kelvin by tilde id AA24814; Thu, 22 Dec 88 15:35:10 CST
Message-Id: <2807818509-4565574@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 22 Dec 88 15:35:09 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU, X3J13@DSG.csc.ti.com
Subject: Re: Issue: LISP-PACKAGE-NAME (Version 1)
In-Reply-To: Msg of Thu, 22 Dec 88 14:03 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> Proposal (LISP-PACKAGE-NAME:COMMON-LISP):
>
> Define that ANSI Common Lisp uses the package name COMMON-LISP, not LISP.
> Define that the COMMON-LISP package has nickname CL.
>
> Since some symbols (e.g., T, NIL, and LAMBDA) might have to be shared
> between COMMON-LISP and LISP in implementations simultaneously supporting
> both, clarify that the initial symbols specified by ANSI Common Lisp as
> belonging in the COMMON-LISP package need not have a home package of
> Common-Lisp.
I like this. I wonder, though, if you might want to add that it would be
permissible for implementations to define "LISP" as a nickname for this
package, for the sake of backwards compatibility in new implementations
that wouldn't otherwise have a "LISP" package?
> Cost to Implementors:
>
> Small.
>
> In some cases, this may even have `negative cost' because it will provide
> implementors a way of avoiding incompatible changes to released operators.
I agree; this approach will make it much easier for us to support the
standard with minimal incompatibility for existing programs. Trying to
support Zetalisp and Common Lisp sharing the same LISP package has been
enough of a headache without having to try to support two dialects of
Common Lisp that way.
Now we just need something in the *FEATURES* list to enable easy
distinction between standard-conforming and pre-standard implementations.
∂22-Dec-88 1545 CL-Cleanup-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Dec 88 15:45:39 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 511675; 22 Dec 88 18:44:30 EST
Date: Thu, 22 Dec 88 18:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881222184414.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Michael Greenwald at Symbolics raised this issue on the Common-Lisp
mailing list. I ran this proposal draft by him. He agrees the writeup
expresses the issue he was trying to raise, and he says he has no
preference for which of the two proposals is adopted. He just wants
us to take some definitive position so he'll know what to implement
for Genera. He asked not to be cc'd in the mail from this point out.
-kmp
-----
Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA
Forum: Cleanup
References: Back quote (pp349-351)
Category: CLARIFICATION/CHANGE
Edit history: 22-Dec-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The consistent description of backquote has been disrupted by
recent changes in the semantics of APPEND.
The description at the bottom of p350 suggests that
`(foo ,@bar) can be legitimately interpreted as any of
#1: (list* 'foo bar)
#2: (append (list 'foo) bar)
#3: (append (list 'foo) bar '())
Unfortunately, issue APPEND-DOTTED has disrupted the equivalences
here because if BAR holds a dotted list, #1 and #2 are the same (they
preserve the `dotted cdr'), but #3 is different (it replaces the
`dotted cdr' with NIL). Under CLtL, a dotted list given to APPEND was
an error, so this case did not come up. But since ANSI CL will not make
this an error, this ambiguity must be resolved.
Proposal (BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:DIVERGENT):
Define that `(x1 ... xM . ,xN) is equivalent to (LIST* x1 ... xN).
The actual (EQL) object xN will be used without copying in the result.
The result itself might not be a proper list (e.g., if xN is an
atom or dotted list).
Define that `(x1 ... xM ,@xN) is equivalent to
(APPEND (LIST 'x1) ... (list 'xM) xN '()).
Any top-level list structure of the object xN will be copied in the
result, replacing (CDR (LAST xN)) with NIL (or replacing xN itself
with NIL if xN is an atom and issue APPEND-ATOM passes).
Proposal (BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:INTERCHANGEABLE):
Define that `(x1 ... xM . ,xN) is equivalent to (LIST* x1 ... xN).
The actual (EQL) object xN will be used without copying in the result.
The result itself might not be a proper list (e.g., if xN is an
atom or dotted list).
Define that `(x1 ... xM ,@xN) is equivalent to
(APPEND (LIST 'x1) ... (list 'xM) xN).
The actual (EQL) object xN will be used without copying in the result.
The result itself might not be a proper list (e.g., if xN is an
atom or dotted list).
Notes:
Note well that this has implications which go beyond dotted lists.
Currently, `(FOO ,@X) may be implemented by either
(LIST* 'FOO X)
or (APPEND (LIST 'FOO) X '())
or (APPEND (LIST 'FOO) X)
A consequence of the proposals above is to distinguish between
the two APPEND cases, forcing changes in the side-effect behavior
of backquoted structures currently exhibited by some implementations.
Test Cases:
;; Issue #1: Non-side-effect treatment of dotted lists.
(LET ((DOTTED (LIST* 'A 'B 'C)))
(VALUES `(FOO ,@DOTTED)
`(FOO . ,DOTTED)))
=> (FOO A B), (FOO A B . C) ;under proposal DIVERGENT
=> (FOO A B . C), (FOO A B . C) ;under proposal INTERCHANGEABLE
;; Issue #2a: Side-effects
;; Sometimes called the ``Standard Backquote Screw''
;; Structure is unintentionally shared.
(LET ((TAIL1 (LIST 'A 'B 'C))
(TAIL2 (LIST 'A 'B 'C)))
(FLET ((GET-XABC-COMMA-ATSIGN () `(X ,@TAIL1))
(GET-XABC-DOT-COMMA () `(X . ,TAIL2)))
(LET ((TEMP1 (GET-XABC-COMMA-ATSIGN))
(TEMP2 (GET-XABC-DOT-COMMA)))
(SETF (CADDR TEMP1) 'Z)
(SETF (CADDR TEMP2) 'Z)
(VALUES TEMP1 (GET-XABC-COMMA-ATSIGN)
TEMP2 (GET-XABC-DOT-COMMA)))))
=> (X A Z C), (X A B C), (X A Z C), (X A Z C) ;under proposal DIVERGENT
=> (X A Z C), (X A Z C), (X A Z C), (X A Z C) ;under proposal INTERCHANGEABLE
;; Issue #2b: Side-effects
;; Sometimes called ``Inverse Backquote Screw''
;; Structure is unintentionally copied.
(LET ((VAR 'X)
(VAL '7)
(THE-SETQ-TAIL (LIST NIL NIL)))
(LET ((COMMA-ATSIGN `(SETQ ,@THE-SETQ-TAIL))
(DOT-COMMA `(SETQ . ,THE-SETQ-TAIL)))
(SETF (CAR SETQ-TAIL) VAR)
(SETF (CADR SETQ-TAIL) VAL)
(VALUES COMMA-ATSIGN DOT-COMMA)
=> (SETQ NIL NIL), (SETQ X 7) ; under proposal DIVERGENT
=> (SETQ X 7), (SETQ X 7) ; under proposal INTERCHANGEABLE
Rationale:
This clarifies an ambiguity in the description of the language which was caused
by issue APPEND-DOTTED and APPEND-ATOM.
Although CLtL tries not to specify the sharing and side-effect implications
of backquote, there is no really principled reason for its failure to do so.
In practice, the failure to do so leads to gratuitous portability barriers.
Current Practice:
Currently, the definition of APPEND is such that it would be an error
to pass it a dotted list, so there is no possibility of discrepancy
because the interesting case is an "is an error" case.
Cost to Implementors:
Very small. Some implementations would need to change how they implement
backquote. Presumably this is a very isolated change.
Cost to Users:
Technically, none. Existing code is not supposed to rely on the distinctions
discussed here. The distinction will only be meaningful when ANSI CL goes into
effect.
In practice, since some implementations will have to change incompatibly,
some code which accidentally relies on the current behavior will break.
However, once such code is fixed, it will be more portable because
implementations will not gratuitously diverge.
Cost of Non-Adoption:
An ambiguity would exist in the language, confusing both users and
implementors.
Benefits:
An ambiguity would be removed.
Some gratuitous barriers to portability would be removed.
Aesthetics:
Proposal DIVERGENT makes things slightly harder to learn.
Both proposals make things more predictably portable, which presumably
has some aesthetic appeal.
Discussion:
Pitman thinks that either of these choices will be better than the status quo.
Given that some people already think of ., and ,@ as interchangeable and merely
a matter of personal style, it would be better to go with option INTERCHANGEABLE.
∂22-Dec-88 1614 CL-Cleanup-mailer Re: Issue: LISP-PACKAGE-NAME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Dec 88 16:14:46 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 511685; 22 Dec 88 19:13:34 EST
Date: Thu, 22 Dec 88 19:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LISP-PACKAGE-NAME (Version 1)
To: Gray@DSG.csc.ti.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU,
X3J13@DSG.csc.ti.com
In-Reply-To: <2807818509-4565574@Kelvin>
Message-ID: <881222191318.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 22 Dec 88 15:35:09 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> Proposal (LISP-PACKAGE-NAME:COMMON-LISP):
>
> Define that ANSI Common Lisp uses the package name COMMON-LISP, not LISP.
> Define that the COMMON-LISP package has nickname CL.
>
> Since some symbols (e.g., T, NIL, and LAMBDA) might have to be shared
> between COMMON-LISP and LISP in implementations simultaneously supporting
> both, clarify that the initial symbols specified by ANSI Common Lisp as
> belonging in the COMMON-LISP package need not have a home package of
> Common-Lisp.
I like this. I wonder, though, if you might want to add that it would be
permissible for implementations to define "LISP" as a nickname for this
package, for the sake of backwards compatibility in new implementations
that wouldn't otherwise have a "LISP" package?
Anyone wanting to make LISP a nickname could just as well create a LISP
package which simply imported the appropriate symbols from the CL package.
With only modest additional effort, they could try to make new symbols where
feasable (especially for most functions) and put borrowed functions plopped
in their function cells. The amount of additional storage is small (compared
to implementing a whole new lisp), but it would leave open the possibility for
users upgrading the level of compatibility without hurting the core
system. eg, if I wanted APPEND to signal an error on dotted lists, I
would not consider redefining the system's APPEND for fear of breaking
the world, but if they told me that nothing depended on LISP other than
compatibility code, I might feel ok about redefining (or doing
SHADOWING-IMPORT of LISP:APPEND on a per-implementation basis (with
appropriate sharp conditionals)) in order to up the level of
compatibility.
In fact, though, my guess is that implementations which are not going to
do a serious compatibility effort are better off leaving the package
missing. My experience has been that customers are often happier growing
their own compatibility [or getting it from a public library] than being
stuck with something which really doesn't do what they want but which
seals off the place in the namespace which they needed in order to do
their own thing.
For this reason, I think we should discourage or prohibit the placement
of a LISP nickname on the CL package.
Besides, ANSI CL supersedes CLtL, but ISO Lisp may not. Depending on how
it turns out, I could see people considering them siblings rather than
mother/daughter. I really believe the bit about not wanting to lock down
the name LISP for a dialect that may not be the unique favorite.
> Cost to Implementors:
>
> Small.
>
> In some cases, this may even have `negative cost' because it will provide
> implementors a way of avoiding incompatible changes to released operators.
I agree; this approach will make it much easier for us to support the
standard with minimal incompatibility for existing programs. Trying to
support Zetalisp and Common Lisp sharing the same LISP package has been
enough of a headache without having to try to support two dialects of
Common Lisp that way.
Now we just need something in the *FEATURES* list to enable easy
distinction between standard-conforming and pre-standard implementations.
In Cloe, we use a separate readtable for the different dialects, and each dialect
has its own *FEATURES* list. Although this seems like it would be confusing, it
works out pretty well in practice once you've made all the system tools understand
it. If we specified that CLtL and ANSI CL could have similar readtables but that
they must not be EQ (for the sake of #+ and #-), and if we defined that
(NOT (EQ 'CL:*FEATURES* 'LISP:*FEATURES*)), then we could indeed have such a feature.
If I get a little time (worn out joke), I'll see about see about spinning off an
issue to deal with that and see if it flies. I know it's last minute, but I agree
with you that it would really grease the wheels of transition, so hopefully people
will find it palatable.
∂27-Dec-88 1209 CL-Cleanup-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Dec 88 12:08:57 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00336g; Mon, 26 Dec 88 22:12:24 PST
Received: by bhopal id AA01403g; Mon, 26 Dec 88 22:13:04 PST
Date: Mon, 26 Dec 88 22:13:04 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812270613.AA01403@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Thu, 22 Dec 88 18:44 EST <881222184414.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
re Cost to Users:
Technically, none. Existing code is not supposed to rely on ...
Not so! The language of the last line on P.350 of CLtL make it clear
that implementations are currently free to take either choice mentioned
in the two proposals. Since not everyone restricts himself to writing
only portable-by-the-book CLtL code, then many users will in fact take
advantage of the particular choices made by the implementation they use.
[Witness the number of Symbolics users who unknowingly adjust arrays that
were made without the :adjustable option].
Selecting only one the two alternatives of P.350 will invalidate those
implementations that have taken the other choice; so either proposal
will shaft some community of users (i.e., those who have never ported
their code between vendors that took different paths on the P.350
question). I know, because we just went through such an exercise here
at Lucid not too long ago. Far too many places depended on the
equivalence of ., and ,. -- that the last form *not* be NCONC'd with
with NIL -- and at least a couple places actually depended upon a final
,@ giving shared structure (for updates to be communally visible).
Incidentally, Lucid adopted a view towards non-standard lists long, long
ago that forced it to resolve the APPEND-DOTTED issue for itself; thus it
is not true of "Current Practice:" that there is "no possibility of
discrepancy". I'm not necessarily defending that view of dotted-lists --
merely pointing out that Lucid's decision back in October 1984 makes the
INTERCHANGEABLE proposable infeasible without backing out of infinitely-many
more dotted-list type decisions. ["infinitely-many more" means that we
worried about just this issue sometime in late 1986, and decided we didn't
have the manpower to resolve it, since it turns up pervasively throughout
the system.] In defence of the 1984 decision, someone who was here at the
time claimed that they personally asked Guy Steele about that interpretation,
and that "he approved". Perhaps no one was concerned back then with the
examples on ClTL P.351.
I actually think the DIVERGENT proposal is simpler to understand:
(1) ,@ always copies -- not to worry about being "at the end"
(2) ,. always NCONC's and ., never NCONC's -- not to worry about
situations that would switch meanings.
-- JonL --
∂27-Dec-88 1716 CL-Cleanup-mailer Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 27 Dec 88 17:16:34 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 414776; Tue 27-Dec-88 11:27:49 EST
Date: Tue, 27 Dec 88 11:26 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881227112629.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
To my knowledge, this was discussed (well, ok, one message was sent on
the subject) but never formally written up.
Actually, I took the writeup of PATHNAME-TYPE-UNSPECIFIC and expanded
it slightly to accomodate other fields. I wrote it up and included the
issue PATHNAME-TYPE-UNSPECIFIC with it. If people seem happy with this
writeup, Larry can consider PATHNAME-TYPE-UNSPECIFIC withdrawn.
If this one runs into some hidden snag, I'll reactivate
PATHNAME-TYPE-UNSPECIFIC.
Note that Larry's original message on PATHNAME-UNSPECIFIC-COMPONENT
deals with some things unrelated to the issue of unspecific components.
I haven't lost that information; it will appear in a different proposal,
soon to follow.
-kmp
-----
Issue: PATHNAME-UNSPECIFIC-COMPONENT
Forum: Cleanup
References: File System Interface (pp409-427)
Category: CHANGE
Edit history: 27-Dec-88, Version 1 by Pitman
Status: For Internal Discussion
Subsumes: Issue PATHNAME-TYPE-UNSPECIFIC
Problem Description:
In some file systems, it is inappropriate to represent particular
pathname components, either all the time or in some specialized
circumstance.
- Unix pathnames never have a version field.
- In some file systems, specifying a device and a directory means
something very different than specifying the device alone,
particularly when the device is a "logical device" that may
already imply a directory.
- Some Unix pathnames have types and others do not. For example,
it is possible to make files named "foo." and "foo" which are
distinct. CLtL (p412) specifies that the type is ``always a
string, NIL, or :WILD.'' This description is too restrictive
to be practical in this case. One of these (usually the former)
can get a type of "" but it is not clear how to represent the
other. If NIL is used, merging primitives cannot detect that the
field is filled and should not be merged against.
- ITS pathnames have either a version or a type, but never both.
"JOE;FILE 32" has a directory, a name, and a version.
"JOE;FILE TEXT" has a directory, a name, and a type.
"JOE;FILE TEXT 32" is not a possible ITS filename.
Proposal (PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN):
Permit :UNSPECIFIC as a value of the DEVICE, DIRECTORY, TYPE, or
VERSION field of a pathname for file systems in which it makes sense.
When a pathname is converted to a namestring, NIL and :UNSPECIFIC
are treated as if the field were empty. That is, they both cause the
component not to appear in the string.
When merging, however, only a NIL value for a component will be
replaced with the default for that component, while :UNSPECIFIC
will be left alone as if the field were filled.
Portable programs should expect to find :UNSPECIFIC in the device,
directory, type, or version field in some implementations.
Portable programs should not explicitly place :UNSPECIFIC in any
field, since that it might not be permitted in some situations,
but portable programs may sometimes do so implicitly.
Test Case:
;; #1: Non-portable code. This may signal an error in some
;; implementations where an unspecific type makes no sense.
(MAKE-PATHNAME :TYPE :UNSPECIFIC) ;not portable
;; #2: In this example, assume a Unix file system.
(PATHNAME-TYPE (PARSE-NAMESTRING "foo."))
=> ""
(PATHNAME-TYPE (PARSE-NAMESTRING "foo"))
=> :UNSPECIFIC
(PATHNAME-TYPE (MERGE-PATHNAMES (PARSE-NAMESTRING "foo")
(MAKE-PATHNAME :TYPE "BAR")))
=> :UNSPECIFIC
;; #3: In this example, assume an ITS file system.
(LET ((P (PARSE-NAMESTRING "FOO 32")))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> (:UNSPECIFIC 32)
(LET ((P (PARSE-NAMESTRING "FOO TEXT")))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> ("TEXT" :UNSPECIFIC)
(LET ((P (MERGE-PATHNAMES (PARSE-NAMESTRING "FOO 32")
(PARSE-NAMESTRING "FOO TEXT"))))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> (:UNSPECIFIC 32)
;; Note: It is not the intent of this proposal to actually legislate
;; the canonical representation of Unix pathnames "foo." and "foo",
;; nor of ITS pathnames "FOO 32" and "FOO TEXT". That should probably
;; be done, but under separate cover. The above examples are intended
;; only to demonstrate how this proposal will permit the representation
;; of pathnames not usefully representable under CLtL.
Rationale:
This is, by necessity, current practice in some implementations
already.
Current Practice:
Symbolics Genera uses a file types and versions of :UNSPECIFIC on
Unix and ITS file systems, for example.
Cost to Implementors:
None. No change to any implementation is forced.
Some implementations which already do this are legitimized.
Some implementations which use a non-standard token other than
:UNSPECIFIC to implement this functionality would want to switch
to use :UNSPECIFIC so that portable programs could expect it.
Cost to Users:
Some programs which manipulate pathnames should be updated to expect
:UNSPECIFIC in the type fields in some situations.
Any program which doesn't already expect :UNSPECIFIC is already not really
portable, however, given that some implementations have been forced to
go beyond the standard in order to represent all possible pathnames.
Cost of Non-Adoption:
Some implementations would be unable to both represent all possible
pathnames in a rational way and at the same time to conform to the
standard. Such an inability would seriously jeopardize the usefulness
of Common Lisp in the design of serious programs.
Benefits:
Some programs involving pathnames would be more portable.
Aesthetics:
Sweeping a hairy situation under the rug doesn't make it go away.
This change makes things appear less simple, but since in reality
they were less simple, it is effectively a simplification of the
correspondence between the CL model and reality.
Discussion:
Pitman and Moon support PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.
This feature existed (for types) in the Colander draft edition of
CLtL, but was removed for the Laser edition. The following text is
excerpted from the Colander edition, p259:
``??? Query: Is :unspecific really needed over and above nil?
``A component of a pathname can also be the keyword
:UNSPECIFIC. This means that the component has been explicitly
determined not to be there, as opposed to be missing. One way
this can occur is with generic pathnames, which refer not to
a file but to a whole family of files. The version, and usually
the type, of a generic pathname are :unspecific. Another way
:unspecific is used to represent components that are not simply
supported by a file system. When a pathname is converted to a
namestring, nil and :unspecific both cause the component not to
appear in the string. When merging, however, a nil value for
a component will be replaced with the default for that
component, while :unspecific will be left alone.''
∂27-Dec-88 1724 CL-Cleanup-mailer Issue: SETF-SUB-METHODS
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 27 Dec 88 17:24:10 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 27 Dec 88 20:16:59 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 27 Dec 88 20:22:08 EST
Date: Tue, 27 Dec 88 20:22 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: SETF-SUB-METHODS
To: cl-cleanup@sail.stanford.edu
Message-Id: <19881228012217.3.BARMAR@OCCAM.THINK.COM>
I have a question about the SETF-SUB-METHODS issue, which clarifies the
order of "evaluation" of access forms that are generalized variable
references.
The Cost to Users section only mentions the incompatibilities caused by
implementations changing to the required behavior. What about users who
have implemented their own complex DEFINE-SETF-METHODs? Will they need
to change these if they wish their generalized variables to be
consistent with the language-defined ones? Or does this not affect the
return values from a SETF method?
barmar
∂28-Dec-88 1133 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Dec 88 11:33:42 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 512753; Wed 28-Dec-88 14:32:32 EST
Date: Wed, 28 Dec 88 14:32 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <881228143206.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Ok, I've been through and I think successfully merged all the pending
discussion, most of which seemed to center around issues of :UP.
-----
Issue: PATHNAME-SUBDIRECTORY-LIST
References: Pathnames (pp410-413), MAKE-PATHNAME (p416),
PATHNAME-DIRECTORY (p417)
Category: CHANGE
Edit history: 18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM
05-Jul-88, Version 2 by Pitman (major revision)
28-Dec-88, Version 3 by Pitman (merge discussion)
Status: For Internal Discussion
Related-Issues: PATHNAME-COMPONENT-CASE
Problem Description:
It is impossible to write portable code that can produce a pathname
in a subdirectory of a hierarchical file system. This defeats much of
the purpose of having an abstraction like pathname.
According to CLtL, only a string is a portable filler of the directory
slot, but in order to denote a subdirectory, the use of separators (such
as dots, slashes, or backslashes) would be necessary. The very fact that
such syntax varies from host to host means that although the
representation might be "portable", the code using that representation
is not portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
Related problems:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO" while in other implementations because "." is not the
separator. To be safe, portable programs must avoid all potential
separators.
- Even in implementations where "." is the separator, "FOO.BAR" may be
recognized by some to mean the "BAR" subdirectory of "FOO" and by others
to mean `a seven letter directory with "." being a superquoted part of
its name'.
- In fact, CLtL does not even say for toplevel directories whether the
directory delimiters are a part. eg, is "foo" or "/foo" the directory
filler for a unix pathname "/foo/bar.lisp". Similarly, is "[FOO]" or
"FOO" the directory filler for a VMS pathname "[FOO]ME.LSP"?
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
Allow a list to be a filler of a pathname. The car of the list may be either
of the symbols :ABSOLUTE or :RELATIVE.
If the car of the list is :RELATIVE, the rest of the list is the
implementation-dependent result of PARSE-NAMESTRING for file systems which
have relative pathnames. Unless some other proposal is submitted to clarify
the behavior of relative pathnames in merging, etc. that behavior is left
undefined.
If the car of the list is :ABSOLUTE, the rest of the list is a list of
strings each naming a single level of directory structure. The strings
should contain only the directory names themselves -- no separator
characters.
The spec (:ABSOLUTE) represents the root directory.
Clarify that if a string is used as a filler of a directory field in a
pathname, it should be the unadorned name of a toplevel directory.
Specifying a string, str, is equivalent to specifying the list
(:ABSOLUTE str).
In place of a string, at any point in the list, keyword symbols may occur
to deal with special file notations. The following symbols have standard
meanings; they may not be meaningful for all operating systems, and are
intended for use only on those operating systems where they have meaning:
:WILD - Wildcard match of one level of directory structure.
:WILD-INFERIORS - Wildcard match of any number of directory levels.
:UP - Go upward in directory structure (semantic).
:BACK - Go upward in directory structure (syntactic).
The difference between up and back is that if there is a directory
(:ABSOLUTE "X" "Y" "Z")
linked to
(:ABSOLUTE "A" "B" "C")
and there also exist directories
(:ABSOLUTE "A" "B" "Q")
(:ABSOLUTE "X" "Y" "Q")
then
(:ABSOLUTE "X" "Y" "Z" :OUT "Q")
designates
(:ABSOLUTE "A" "B" "Q")
while
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
designates
(:ABSOLUTE "X" "Y" "Q")
Test Case:
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "[FOO.BAR]BAZ.LSP")) ;on VMS
=> (:ABSOLUTE "FOO" "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/baz.lisp")) ;on Unix
=> (:ABSOLUTE "foo" "bar")
or (:ABSOLUTE "FOO" "BAR")
If PATHNAME-COMPONENT-CASE:CANONICALIZE passes, only the 2nd return value.
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>**>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
Rationale:
This would allow programs to usefully deal with hierarchical file systems,
which are by far the most common file system type.
Current Practice:
Symbolics Genera implements something very similar to this. The main
differences are:
- In Genera, there is no :ABSOLUTE keyword at the head of the list.
This has been shown to cause some problems in dealing with root
directories. Genera represents the root directory by a keyword
symbol (rather than a list) because the list representation
was not adequately general.
- Genera represents Unix ".." as :UP, but deals with :UP
syntactically, not semantically.
Cost to Implementors:
In principle, nothing about the implementation needs to change except
the treatment of the directory field by MAKE-PATHNAME and
PATHNAME-DIRECTORY. The internal representation can otherwise be left
as-is if necessary.
For implementations that choose to rationalize this representation
throughout their internals and any other implementation-specific
accessors, the cost will be necessarily higher.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Serious portability problems would continue to occur. Programmers would be
driven to the use of implementation-specific facilities because the need
for this is frequently impossible to ignore.
Benefits:
The serious costs of non-adoption would be avoided.
Aesthetics:
This representation of hierarchical pathnames is easy to use and quite
general. Users will probably see this as an improvement in the aesthetics.
Discussion:
This issue was raised a while back but no one was fond of the particular
proposal that was submitted. This is an attempt to revive the issue.
The original proposal, to add a :SUBDIRECTORIES field to a pathname, was
discarded because it imposed an unnatural distinction between a toplevel
directory and its subdirectories. Pitman's guess is the the idea was to
try to make it a compatible change, but since most programmers will
probably want to change from implementation-specific primitives to portable
ones anyway, that's probably not such a big deal. Also, there might have
been some programs which thought the change was compatible and ended up
ignoring important information (the :SUBDIRECTORIES field). Pitman thought
it would be better if people just accepted the cost of an incompatible
change in order to get something really pretty as a result.
This issue used to address the issue of relative pathnames (pathnames
relative to some default which is separately maintained). Pitman removed
this issue for now in order to simplify things. He feels the issue should
be resubmitted under separate cover so that it can be discussed separately.
∂28-Dec-88 1259 CL-Cleanup-mailer Issue: PATHNAME-EXTENSIONS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Dec 88 12:58:49 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 512793; Wed 28-Dec-88 15:57:35 EST
Date: Wed, 28 Dec 88 15:57 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-EXTENSIONS (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <881228155709.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: PATHNAME-EXTENSIONS
Forum: Cleanup
References: Pathnames (pp410-413)
Category: ADDITION
Edit history: 28-Dec-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL is quite strict about what may and may not be in any kind of
pathname, leaving implementors up against a brick wall when an
idiosyncratic extension is necessary to uniquely and usefully
represent all files in a particular file system which may not have
been completely anticipated by the Common Lisp designers.
Proposal (PATHNAME-EXTENSIONS:NEW-PREDICATE):
Introduce a function COMMON-PATHNAME-P, described as follows:
COMMON-PATHNAME-P pathname [Function]
Returns true if its argument satisfies the Common Lisp
pathname model, and false otherwise. If the argument is
not a pathname, an error of type TYPE-ERROR is signalled.
Clarify that COMMON-PATHNAME-P considers a pathname's host field
to fit the Common Lisp pathname model if the filler of the host
field is a string (naming a host), and not otherwise.
Clarify that COMMON-PATHNAME-P considers a pathname's device to fit
the Common Lisp pathname model if it is a string naming a device,
or NIL, or :WILD[, or, if issue PATHNAME-COMPONENT-UNSPECIFIC
passes, is :UNSPECIFIC], and not otherwise.
Clarify that COMMON-PATHNAME-P considers a pathname's directory
field to fit the Common Lisp pathname model if the filler of the
directory field is NIL, or :WILD, or a string[, or, if issue
PATHNAME-SUBDIRECTORY-LIST passes, is a list described as valid
by that proposal][, or, if issue PATHNAME-COMPONENT-UNSPECIFIC
passes, is :UNSPECIFIC], and not otherwise.
Clarify that COMMON-PATHNAME-P considers a pathname's name to
fit the Common Lisp pathname model if it is a string, or NIL,
or :WILD, and not otherwise.
Clarify that COMMON-PATHNAME-P considers a pathname's type to
fit the Common Lisp pathname model if it is a string, or :WILD,
or NIL[, or, if issue PATHNAME-COMPONENT-UNSPECIFIC passes, is
:UNSPECIFIC], and not otherwise.
Clarify that COMMON-PATHNAME-P considers a pathname's version to
fit the Common Lisp pathname model if it is a positive integer,
:WILD, or NIL, or :NEWEST[, or, if issue PATHNAME-COMPONENT-UNSPECIFIC
passes, is :UNSPECIFIC], and not otherwise.
Clarify that COMMON-PATHNAME-P considers a pathname to be outside
the Common Lisp model if it contains special syntax or purpose
which is not readily apparent to Common Lisp programs. For example,
if a character like "*" or "~" has special meaning to the file
system, then strings like "F*X" or "~FOO" which exploit that syntax
are not considered to "fit the model". [Note that if issue
PATHNAME-WILD passes, WILD-PATHNAME-P might still be true of
some pathnames that were not COMMON-PATHNAME-P.]
Test Case:
;; On Unix...
(common-pathname-p (make-pathname :name "f*x"))
=> nil
;; On Tops-20...
(common-pathname-p (make-pathname :name "FOO" :version -1))
;; On VMS...
(common-pathname-p (parse-namestring "x::y::z::w::[joe]a.b"))
=> nil
;; Normally
(common-pathname-p (make-pathname :name "FOO" :version :wild))
=> t
(common-pathname-p (make-pathname :name "FOO" :version 17))
=> t
Rationale:
The purpose of COMMON-PATHNAME-P is not to detect pathnames which
are not valid. Indeed, no Common Lisp function requires that its
argument satisfy this test; it is assumed that functions such as
OPEN and MERGE-PATHNAMES will recognize and deal appropriately with
whatever special pathname syntax is appropriate to the host operating
system. Rather, the purpose of COMMON-PATHNAME-P is to help Common
Lisp programs which try to pick apart a pathname and perform some
sort of simulated merging on the basis of the simple pathname model
put forth by Common Lisp, so that such programs can detect situations
which are beyond their capabilities.
Current Practice:
Probably nobody implements this.
Cost to Implementors:
Small. The program is fairly straightforward. It could almost be
written as a portable library if it weren't for detecting special
characters that have some special syntax.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Some idiosyncratic system syntax would be hard to detect.
Making extensions to the pathname system in a way that Common Lisp
users would not be forced to trip over would be more difficult.
Benefits:
Some ad-hoc user code which tries to do the same thing could be
eliminated. Portable programs which must prompt for native pathname
syntax, and deal with the result of having parsed it could be more
robust.
Making idiosyncratic extensions to the pathname system would be much
less prone to cause problem for portable programs which used this
facility.
The presence of this operator could someday ease the transition
into a future, incompatible pathname system.
Aesthetics:
Probably improves aesthetics slightly by giving people who want to
reject extended pathnames a more reliable way of weeding them out.
Discussion:
The COMMON data type was probably intended to have this same purpose.
Unfortunately, since no one ever really said specifically enough what
was in COMMON or not, and why, it never really caught on. Hopefully
this proposal is definite enough on such issues to not be useless.
Pitman thinks this is probably a good idea.
∂29-Dec-88 0353 CL-Cleanup-mailer Issue: SETF-SUB-METHODS
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Dec 88 03:53:21 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00898g; Thu, 29 Dec 88 03:49:55 PST
Received: by bhopal id AA09984g; Thu, 29 Dec 88 03:52:05 PST
Date: Thu, 29 Dec 88 03:52:05 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812291152.AA09984@bhopal>
To: barmar@Think.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 27 Dec 88 20:22 EST <19881228012217.3.BARMAR@OCCAM.THINK.COM>
Subject: Issue: SETF-SUB-METHODS
re: What about users who
have implemented their own complex DEFINE-SETF-METHODs? Will they need
to change these if they wish their generalized variables to be
consistent with the language-defined ones? Or does this not affect the
return values from a SETF method?
Well, I won't say that a programmer who uses DEFINE-SETF-METHOD can't
shaft himself this way [by definition, DEFINE-SETF-METHOD is for the
"not easy" case]. However, this proposal seems more directed towards
stopping the premature optimization where "evaluating a subform" and
"doing the access" are falsly combined into one step. [The original
temptation to do so was when the sub-form was a symbol(?)] I rather
hope, as you suggest, that this proposal affects the return value
of a SETF method only to the degree that the related accessing and
storing forms don't make the premature optimization.
-- JonL --
∂29-Dec-88 1006 CL-Cleanup-mailer Issue: PATHNAME-EXTENSIONS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88 10:06:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513117; Thu 29-Dec-88 13:05:13 EST
Date: Thu, 29 Dec 88 13:04 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-EXTENSIONS (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881228155709.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881229180459.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
This sounds reasonable at first, but I was unable to think of any
way that a correct portable program could use it. If there was a
use for it, I couldn't convince myself that a single yes/no distinction
was sufficient; some extensions to Common Lisp pathname semantics
might be handled by a CL function that the user program was going to
call, thus they wouldn't interfere with use of an "extended" pathname.
Indeed, why isn't this true of all such extensions?
I think you need to supply a real example.
∂29-Dec-88 1031 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88 10:30:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513134; Thu 29-Dec-88 13:29:18 EST
Date: Thu, 29 Dec 88 13:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881228143206.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881229182903.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION but note the
following typos and proposed simplifications. Also, don't you need
functions like Symbolics' DIRECTORY-PATHNAME-AS-FILE and
PATHNAME-AS-DIRECTORY? The conversion between the name of a directory
and the directory component of a file inferior to that directory is
system-dependent, for example TOPS-20 appends a type field and Unix does
not. Also in some systems the root directory has a name and in others
it doesn't. Of course these functions signal an error in
non-hierarchical file systems. Should there be a separate proposal for
these?
Typos (and some discussion):
Problem Description:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO" while in other implementations because "." is not the
separator.
Some words must be missing after "while".
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
:UP - Go upward in directory structure (semantic).
:BACK - Go upward in directory structure (syntactic).
The difference between up and back is that if there is a directory
(:ABSOLUTE "X" "Y" "Z")
linked to
(:ABSOLUTE "A" "B" "C")
and there also exist directories
(:ABSOLUTE "A" "B" "Q")
(:ABSOLUTE "X" "Y" "Q")
then
(:ABSOLUTE "X" "Y" "Z" :OUT "Q")
designates
(:ABSOLUTE "A" "B" "Q")
while
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
designates
(:ABSOLUTE "X" "Y" "Q")
Is :OUT a typo for :BACK? Also I don't understand what your proposed
semantic/syntactic distinction is. I almost thought I did until I read
the above text carefully and saw that the syntactic one chases links
to the truename and the semantic one does not, which seems backwards.
I also don't think :UP and :BACK are meaningful anywhere except immediately
after :RELATIVE, although I have to concede that Unix disagrees with me
and therefore Symbolics Genera's Unix pathname support also disagrees
with me. But if they were only allowed immediately after :RELATIVE I
don't think you would need two of them. I also don't think that
MERGE-PATHNAMES should ever look at what files/directories actually
exist in the file system, which makes me opposed to the existence
of the one that you have called syntactic. Is this really something
we need, or will TRUENAME do the job?
I think we should only have :UP and not :BACK.
Current Practice:
- Genera represents Unix ".." as :UP, but deals with :UP
syntactically, not semantically.
After you straighten out the definition of syntactic and semantic, check
whether this statement is true. (I'm always irked by proposals where
the current practice section is wrong, because someone wrote an original
proposal where the current practice section was right, then the group
changed the proposal all around but didn't update the current practice
section).
Discussion:
This issue used to address the issue of relative pathnames (pathnames
relative to some default which is separately maintained). Pitman removed
this issue for now in order to simplify things. He feels the issue should
be resubmitted under separate cover so that it can be discussed separately.
It seems to me that this fully addresses relative pathnames already. The
discussion of :UP and :BACK (if freed of typos) seems specific enough that
even though this proposal doesn't explicitly propose what MERGE-PATHNAMES
does with relative pathnames, I think there is only one thing that it could
do that would be consistent. A pathname with a :RELATIVE directory is
not very different from a pathname with a NIL directory; in either case
you have to merge with a default to find the real directory to use; thus
I don't think there are any other new issues with relative pathnames.
∂29-Dec-88 1038 CL-Cleanup-mailer Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88 10:38:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513138; Thu 29-Dec-88 13:37:15 EST
Date: Thu, 29 Dec 88 13:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881227112629.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881229183701.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN (of course).
Where you note that Unix pathnames don't have versions, you
could also note that they don't have devices either.
The stuff about generic pathnames in the discussion section
was brain damage and may have lead to the confusion that caused
:unspecific to be dropped from Common Lisp. Only the stuff about
components not supported by a file system makes sense.
∂29-Dec-88 1040 CL-Cleanup-mailer Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88 10:39:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513139; Thu 29-Dec-88 13:38:15 EST
Date: Thu, 29 Dec 88 13:38 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881227112629.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Supersedes: <19881229183701.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Added comment about misspelled proposal name
Message-ID: <19881229183800.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN (of course).
Uh, the proposal name is really spelled that way in the body
of the writeup. It should be PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN.
Where you note that Unix pathnames don't have versions, you
could also note that they don't have devices either.
The stuff about generic pathnames in the discussion section
was brain damage and may have lead to the confusion that caused
:unspecific to be dropped from Common Lisp. Only the stuff about
components not supported by a file system makes sense.
∂29-Dec-88 1119 CL-Cleanup-mailer Issue: PATHNAME-EXTENSIONS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88 11:18:41 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513169; Thu 29-Dec-88 14:17:20 EST
Date: Thu, 29 Dec 88 14:16 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-EXTENSIONS (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19881229180459.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <881229141653.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Here's a made-up example of the kind I was imagining:
(DEFUN TRANSLATE-LOGICAL-PATHNAME (LPATHNAME)
(MULTIPLE-VALUE-BIND (LHOST LDEVICE LDIR LNAME LTYPE LVERSION)
(PARSE-LOGICAL-PATHNAME LPATHNAME)
(MULTIPLE-VALUE-BIND (PHOST PDEVICE PDIR PNAME PTYPE PVERSION)
(TRANSLATE-PATHNAME-COMPONENTS LHOST LDEVICE LDIR LNAME LTYPE LVERSION)
(LET ((PHYSICAL-PATHNAME (MAKE-PATHNAME :HOST PHOST ...)))
(UNLESS (COMMON-PATHNAME-P PHYSICAL-PATHNAME)
(CERROR "Use ~*~A anyway."
"The result of translating pathname ~A to a physical pathname~
~%resulted in a valid physical pathname, ~A,~
~%but that pathname has special meaning to host ~A which may~
~%not have been what was intended."
LPATHNAME PHYSICAL-PATHNAME PHOST))))))
I don't think I have a specific example around, but I remember I used to worry
about this a lot in Macsyma, because LispM Macsyma does cross-host file searches
by mixing and matching file syntaxes gotten from here and there. I used to worry
it would construct pathnames that were magic in some way and do something weird.
If I could have put in an error check here and there, I'd have felt a bit more
comfortable.
Also, CLtL's spec gives so much leeway allowing "implementation-dependent" things
all over the place in pathnames, that I just figured that it would be easier for
users who want to assume the "nice" values are present to just guard simple-minded
code with
(COND ((COMMON-PATHNAME-P PATHNAME)
... code that assumes pathnames don't contain hairy junk ...)
(T
(ERROR "Pathname ~S was more complex than I expected." PATHNAME)))
As clumsy as this error seems, it's probably more informative than the
LENGTH got bad argument or whatever that you'd get instead if you wrote the
same code unguarded. Seems like that would provide at least the opportunity
for fault-tolerant code without giving up the ability to do fast prototyping.
∂29-Dec-88 1132 CL-Cleanup-mailer Issue: PATHNAME-EXTENSIONS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88 11:32:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513176; Thu 29-Dec-88 14:31:07 EST
Date: Thu, 29 Dec 88 14:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-EXTENSIONS (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881229141653.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881229193043.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
The examples only shed negative illumination for me. That is,
I'm not sure what precisely "special meaning", "something weird",
not "nice values", and "hairy junk" really mean. I suspect part of
what you're worried about is wildcard pathnames; wasn't there already
proposed a PATHNAME-WILD-P (or was it WILD-PATHNAME-P?) function for
that?
In one of your examples COMMON-PATHNAME-P seems to mean "this pathname
is acceptable to the host" and in the other example COMMON-PATHNAME-P
seems to mean "this pathname is acceptable to a particular user-written
algorithm". To me those don't seem to be the same test. I think the
former test makes sense to codify as a function (although when I try
to articulate precisely what "acceptable" means, I have trouble; can it
be dynamically varying depending on what files and directories currently
exist?), but I don't see that your proposed function does this test.
The latter test seems hard to specify without saying anything about
the user-written algorithm.
I'm not really opposed to this, but I don't think it's defined
specifically enough yet. I begin to fear that it is inherently
impossible to define it specifically enough.
∂29-Dec-88 1153 CL-Cleanup-mailer Issue: PATHNAME-EXTENSIONS (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Dec 88 11:53:36 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01031g; Thu, 29 Dec 88 11:49:58 PST
Received: by bhopal id AA11022g; Thu, 29 Dec 88 11:52:09 PST
Date: Thu, 29 Dec 88 11:52:09 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8812291952.AA11022@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: Kent M Pitman's message of Wed, 28 Dec 88 15:57 EST <881228155709.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-EXTENSIONS (Version 1)
Does this really need to be a part of the standard? Why can't it
just be privately distributed (or re-invented) by the few sites that
want it? As far as I can see, it is merely a syntax checker which
sits entirely on top of the current language, and anyone who cares
can implement it quickly after reading the standard.
If one is to persue portability in this fashion, I think it would be
more elegant to seriously implement the COMMON data type and have a
pair of predicates that tested any given lisp form and said whether it
was data (or code) that adhered to the common lisp standard. (The
data predicate might itself be written portably. The code predicate
would need to be ported to each vendor to detect supported but
non-standard features, since (TRICKY X) would be standard if TRICKY
were user-defined, but would not be if it implemented some
vendor-specific magic.) Given such predicates you could safely
descend through any lisp structure, using the predicates to warn you
of pitfalls ahead.
Doing bits and pieces of syntax checking seems somewhat ad hoc, unless
the claim is that pathnames are and will be the only "standard" data
which have unpredictable format.
jlm
∂29-Dec-88 1157 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88 11:56:58 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513196; Thu 29-Dec-88 14:54:41 EST
Date: Thu, 29 Dec 88 14:54 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19881229182903.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <881229145413.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 29 Dec 88 13:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
... don't you need functions like Symbolics' DIRECTORY-PATHNAME-AS-FILE and
PATHNAME-AS-DIRECTORY? The conversion between the name of a directory
and the directory component of a file inferior to that directory is
system-dependent, for example TOPS-20 appends a type field and Unix does
not. Also in some systems the root directory has a name and in others
it doesn't. Of course these functions signal an error in
non-hierarchical file systems. Should there be a separate proposal for
these? ...
I guess it's enough related to this topic that it could piggy back.
Certainly these functions made no sense prior to this proposal and
now they are suddenly important, so I'll see about putting them in on
next pass.
... Is :OUT a typo for :BACK? ...
Yeah. Sloppy editing. Sorry.
Also I don't understand what your proposed semantic/syntactic
distinction ...
Semantic means you have to probe the file system. Syntactic means
looking at the file names themselves is enough. Maybe I screwed up
the presentation. I'll double-check.
Genera is syntactic in that it doesn't probe when processing :UP.
That means that MERGE-PATHNAMES on
(:ABSOLUTE "X" "Y" "Z")
and
(:RELATIVE :UP "Q")
returns
(:ABSOLUTE "X" "Y" "Q")
rather than
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
If you were going to contract out the :UP, you'd need to probe the
file system to make sure
(:ABSOLUTE "A" "B" "Q")
wasn't more correct than
(:ABSOLUTE "X" "Y" "Q")
so I think Genera has a bug.
I think this because if I do:
cd /m/n/o
cd ../q
on Unix I get one place, but in Genera if I visit a file in the
editor named
/m/n/o/x.lisp
and then I type c-X c-F and when prompted for a filename I type
../q/x.lisp
I end up with
/m/n/o/q/x.lisp
rather than the x.lisp in the directory that Unix itself would have
plopped me in if I'd used the cd commands above.
If you disagree, please reply to me privately so we can avoid
further confusion, quickly iron it out offline, and then report a
joint answer (and rationale) to everyone else once we've achieved
consensus.
I also don't think :UP and :BACK are meaningful anywhere except immediately
after :RELATIVE, although I have to concede that Unix disagrees with me
and therefore Symbolics Genera's Unix pathname support also disagrees
with me.
When I previously raised this topic, there were a pile of messages on
exactly this subject. My putting these into the proposal was an attempt
to address those topics. Even if I took these out, the current proposal
offers the flexibility that implementations could offer them without being
in violation of the spec. On the other hand, if people -are- going to offer
them, we might as well agree on common names if it's possible to do so.
But if they were only allowed immediately after :RELATIVE I
don't think you would need two of them.
I claim my example above refutes this.
I also don't think that
MERGE-PATHNAMES should ever look at what files/directories actually
exist in the file system,
If you permit :UP in absolute pathnames, you don't have to look in the
file system. You just get some funny names. Most file systems that
have this feature permit such funny names, though. eg, /foo/../bar/x
is valid in Unix, I understand. If memory serves me, Multics permits
>foo>bar>baz<x>y in Multics, no? Our (Symbolics) pathname system doesn't
permit embedded "<", but the error message suggests that this is only
because there's no obvious interpretation. We could define it to mean
:BACK rather than :UP, so that syntactic merges could be done and
unique pathnames would always be generated.
which makes me opposed to the existence
of the one that you have called syntactic.
In any case, I'm sympathetic to your desire to not look in the file
system. I just think that if a file system designer has made a
decision that forces you to look in the file system to get the right
answer, I don't know what we the CL designers can do to alter that.
The same issue comes up for logical devices and as Sandra has reminded
us, we've not done a particularly good job of papering over that real
externally-induced issue either.
Is this really something we need, or will TRUENAME do the job?
TRUENAME and OPEN would, presumably, not return pathnames with :UP
references (except maybe in pathological situations which they tell
me you can make in Unix if you try hard enough where the only way to
get to a directory is to go down first and then dig upward.)
I think we should only have :UP and not :BACK.
Nothing forces a file system to have both. The question is whether
there are some file systems that have one set of semantics and others
which have the other. If so, then two tokens are needed. In the discussion
leading up to this, people asserted (and I took them at their word) that
there were such competing semantics.
Current Practice:
- Genera represents Unix ".." as :UP, but deals with :UP
syntactically, not semantically.
After you straighten out the definition of syntactic and semantic, check
whether this statement is true. (I'm always irked by proposals where
the current practice section is wrong, because someone wrote an original
proposal where the current practice section was right, then the group
changed the proposal all around but didn't update the current practice
section).
I'll double-check when I've made the next version.
Discussion:
This issue used to address the issue of relative pathnames (pathnames
relative to some default which is separately maintained). Pitman removed
this issue for now in order to simplify things. He feels the issue should
be resubmitted under separate cover so that it can be discussed separately.
It seems to me that this fully addresses relative pathnames already. The
discussion of :UP and :BACK (if freed of typos) seems specific enough that
even though this proposal doesn't explicitly propose what MERGE-PATHNAMES
does with relative pathnames, I think there is only one thing that it could
do that would be consistent. A pathname with a :RELATIVE directory is
not very different from a pathname with a NIL directory; in either case
you have to merge with a default to find the real directory to use; thus
I don't think there are any other new issues with relative pathnames.
Well, there was the whole treatment of :UP. I hadn't really meant for this
proposal to specify that treatment so much as to identify a common representation
so we'd be a little less divergent in the areas we hadn't really specified.
Does anyone think I should add a disclaimer in the proposal body similar to the
one for :OLDEST, :INSTALLED, etc in pathname versions in CLtL that says that
although these are semi-standard names, there is no attached semantics?
∂29-Dec-88 1219 CL-Cleanup-mailer Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88 12:18:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513216; Thu 29-Dec-88 15:17:18 EST
Date: Thu, 29 Dec 88 15:16 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
To: CL-Cleanup@SAIL.Stanford.Edu, Pavel.pa@Xerox.COM
In-Reply-To: <881205-182309-4829@Xerox>
Message-ID: <19881229201656.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I support this proposal, especially as modified by GSB's comments.
I'd like to point out that this proposal corresponds exactly to current
practice in Symbolics Genera (all versions from 6.0 on), except that
SHIFTF, ROTATEF, ASSERT, CTYPECASE, and CCASE only allow single values.
You should update the current practice section accordingly.
I think SHIFTF and ROTATEF should allow any number of values, but the
other three (yes, including ASSERT) properly only allow single values.
Do you plan to bring an updated version of this proposal to the
next X3J13 meeting?
∂29-Dec-88 1228 CL-Cleanup-mailer Issue: PATHNAME-EXTENSIONS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88 12:28:43 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513219; Thu 29-Dec-88 15:24:16 EST
Date: Thu, 29 Dec 88 15:23 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-EXTENSIONS (Version 1)
To: jlm@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8812291952.AA11022@bhopal>
Message-ID: <881229152348.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 29 Dec 88 11:52:09 PST
From: Jim McDonald <jlm@lucid.com>
Does this really need to be a part of the standard? Why can't it
just be privately distributed (or re-invented) by the few sites that
want it? As far as I can see, it is merely a syntax checker which
sits entirely on top of the current language, and anyone who cares
can implement it quickly after reading the standard.
The answer to this is in the proposal (Cost to Implementors):
Small. The program is fairly straightforward. It could almost be
written as a portable library if it weren't for detecting special
characters that have some special syntax.
A truly portable program cannot know that "*" or "~" or whatever
is special to some file systems and not to others.
If one is to persue portability in this fashion, I think it would be
more elegant to seriously implement the COMMON data type
I'd be really surprised if you could come up with a meaning for this
as a type. I could imagine you almost coming up with a meaning for COMMON
which was representable as a predicate, but I don't think you could do
it as a type. It's clear that some non-COMMON data types have to be
subtypes of COMMON. For example, arrays with array leaders on the 3600.
You might write a COMMON-P predicate which detected this, but you'd be
misled by subtypep relations if you really pursued this as part of the
type system.
and have a
pair of predicates that tested any given lisp form and said whether it
was data (or code) that adhered to the common lisp standard.
If you want to write a description of such a predicate, I think we should
have it. But I don't think you could describe it adequately, so I was biting
off a particular part of the problem that has some real world application.
Pathnames are interestingly different from other CL data because they involve
a syntax (namestrings) which are specified by an external agency (the file
system) and which correspond to data structures (directories, links, files,...)
which are also really beyond the scope of CL to legislate. As such, they are
more prone to legitimately deviate than other aspects of CL data. At least
in the case of other data, you can argue that the implementors could have
opted to not provide the extensions (eg, array leaders). You can't argue
that CL implementors should fail to support some kinds of files just because
the CL model doesn't suppor them. They must support all files, or CL programmers
will be laughed at by their friends that use -real- programming languages.
If they do support all files, then either we must have amazing foresight in
choosing just the right pathname model, or we must guard ourselves by providing
ways for CL implementors to legitimately deviate without screwing up normal
programs.
(The data predicate might itself be written portably.
It cannot be written portably. Examples:
- From Scheme: Scheme does not define a way to adjust the length of
a STRING. Unfortunately, some implementations do. The Scheme spec
did not define (EQL "" ""), but did define that operationally
equivalent data was EQL. Since the only side-effecting string
operations in Scheme set a string element (and don't change its
size), then "" can't be side-effected, and so by implication
(EQL "" "") should return T. However, some implementations extended
Scheme to provide operations to change a string's length. Those
operations (rightly, I think) interpreted the spec to say that
(EQL "" "") could return NIL. No portable predicate on "" can
detect that someone has added an operation that makes "" not fit
the model that Scheme had for strings. The issue here is that
sometimes it's the operators which cause the confusion, not the
data layout, so making a function just on data is not necessarily
helpful.
- From Genera: What portable operation can detect that an array has
a leader (given that EQUAL ignores leaders). Answer: None. You have
to use implementation-dependent means to detect
implementation-dependent features!
- From Star Trek: Spock: "Captain, I'm registering a kind of energy
never before encountered." Man, the guys who designed his scanner
were geniuses...
The code predicate would need to be ported to each vendor to
detect supported but non-standard features,
Then what's the point of claiming it's portable?
since (TRICKY X) would be standard if TRICKY
were user-defined, but would not be if it implemented some
vendor-specific magic.)
What is "it" in this sentence?
Given such predicates you could safely descend through any lisp
structure, using the predicates to warn you of pitfalls ahead.
Given the above, I think this is naive.
Doing bits and pieces of syntax checking seems somewhat ad hoc, unless
the claim is that pathnames are and will be the only "standard" data
which have unpredictable format.
Well, as I mentioned above, there's a real empirical reason to believe
that if not the only one in that `class,' they are at least part of an
elite group. Streams might be another candidate, but I don't happen to
be interested in that.
In any case, I have grown very weary of arguments of the form
"Gosh, you thought up an interesting thing there, but before
I'll agree with it, I think you should generalize it a lot more
for no apparent reason." Lots of things we've proposed as cleanups
are incidences of larger problems, but I think we ought to just consider
what's proposed. If it's important to someone to solve the more general
case, let them write the proposal and I (at least) will consider it for
what it's worth. But in the absence of such a general proposal, I don't
agree that it's best to just admit defeat and do nothing. There is a lot
to be gained by solving subsets of problems and gaining experience for
the next round. Maybe ten years from now we'll know if a primitive like
this had unforseen problems, we'll know if it got any (or a lot of) use,
etc. The COMMON type was an example. It was a noble experiment and
probably should be put to death now that it's been demonstrated to be a
loser. But it didn't cost users at all, and it didn't cost implementors
much (an evening each of lost sleep for a few implementors here and there)
to have it there -- and we learned something in the process.
∂29-Dec-88 1308 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88 13:07:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513261; Thu 29-Dec-88 16:05:23 EST
Date: Thu, 29 Dec 88 16:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881229145413.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881229210501.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 29 Dec 88 14:54 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Thu, 29 Dec 88 13:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Also I don't understand what your proposed semantic/syntactic
distinction ...
Semantic means you have to probe the file system. Syntactic means
looking at the file names themselves is enough. Maybe I screwed up
the presentation. I'll double-check.
OK, I understand, and you did screw up the presentation.
But if they were only allowed immediately after :RELATIVE I
don't think you would need two of them.
I claim my example above refutes this.
Agreed.
I also don't think that
MERGE-PATHNAMES should ever look at what files/directories actually
exist in the file system,
If you permit :UP in absolute pathnames, you don't have to look in the
file system. You just get some funny names. Most file systems that
have this feature permit such funny names, though. eg, /foo/../bar/x
is valid in Unix, I understand. If memory serves me, Multics permits
>foo>bar>baz<x>y in Multics, no?
No. Although that's from memory: there are few Multices left, I don't
have an account of any of them, and my manuals are in the attic at home.
I think you got syntactic and semantic mixed up again. I think you're
saying that MERGE-PATHNAMES of a relative directory against an absolute
directory will remove :UP, since that's purely syntactic, but will leave
:BACK in the middle of the merged directory, since resolving :BACK
"semantically" would require accessing the file system, which
MERGE-PATHNAMES doesn't do. Okay.
These names are extremely confusing, obviously. Can anyone think
of better ones than :UP and :BACK?
Our (Symbolics) pathname system doesn't
permit embedded "<", but the error message suggests that this is only
because there's no obvious interpretation.
The error message I get doesn't suggest anything, it's just "Embedded <?".
We could define it to mean
:BACK rather than :UP, so that syntactic merges could be done and
unique pathnames would always be generated.
I don't understand this sentence. Say it again after we all agree on
which one is :UP and which one is :BACK.
which makes me opposed to the existence
of the one that you have called syntactic.
In any case, I'm sympathetic to your desire to not look in the file
system. I just think that if a file system designer has made a
decision that forces you to look in the file system to get the right
answer, I don't know what we the CL designers can do to alter that.
The same issue comes up for logical devices and as Sandra has reminded
us, we've not done a particularly good job of papering over that real
externally-induced issue either.
Is this really something we need, or will TRUENAME do the job?
TRUENAME and OPEN would, presumably, not return pathnames with :UP
references (except maybe in pathological situations which they tell
me you can make in Unix if you try hard enough where the only way to
get to a directory is to go down first and then dig upward.)
I think we should only have :UP and not :BACK.
Nothing forces a file system to have both. The question is whether
there are some file systems that have one set of semantics and others
which have the other. If so, then two tokens are needed. In the discussion
leading up to this, people asserted (and I took them at their word) that
there were such competing semantics.
I don't know enough about the weird file systems out there to dispute this.
Well, there was the whole treatment of :UP. I hadn't really meant for this
proposal to specify that treatment so much as to identify a common representation
so we'd be a little less divergent in the areas we hadn't really specified.
Does anyone think I should add a disclaimer in the proposal body similar to the
one for :OLDEST, :INSTALLED, etc in pathname versions in CLtL that says that
although these are semi-standard names, there is no attached semantics?
Yes, I think :UP and :OLDEST have the same status, but no I don't agree
that that status is that they have no semantics. I agree with what CLtL
page 412 actually says, which is that either an implementation doesn't
support these keywords or if it does support them they have prescribed
meanings.
∂29-Dec-88 1451 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Dec 88 14:51:48 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01199g; Thu, 29 Dec 88 14:46:14 PST
Received: by bhopal id AA11773g; Thu, 29 Dec 88 14:48:23 PST
Date: Thu, 29 Dec 88 14:48:23 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8812292248.AA11773@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Thu, 29 Dec 88 13:29 EST
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
>> Is this really something we need, or will TRUENAME do the job?
If you're trying to create a filename to be used for output, it might
not exist yet (hence TRUENAME would signal an error), but there might
be various funny links in its directory path you would like to
traverse. Presumably you could use PROBE-FILE on some part of the
name (perhaps recursively down through the super-directories), then
merge in the remaining part, but that seems enough error-prone to be
worth hiding.
BTW, I think the labelling of semantic/syntactix examples was reversed
in the proposal, independantly of :UP vs. :BACK.
jlm
∂29-Dec-88 1834 CL-Cleanup-mailer Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 29 Dec 88 18:33:53 PST
Received: by ti.com id AA06901; Thu, 29 Dec 88 20:33:36 CST
Received: from dsg by tilde id AA24175; Thu, 29 Dec 88 20:22:52 CST
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 29 Dec 88 20:20:40 CST
Message-Id: <2808440631-7583328@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 29 Dec 88 20:23:51 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
In-Reply-To: Msg of Thu, 22 Dec 88 18:44 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I ran all of the test cases on an Explorer and found that the results were
all consistent with proposal
BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:INTERCHANGEABLE, so I would have to
prefer that alternative, although I don't know who might be depending on
that behavior.
The INTERCHANGEABLE alternative also has a performance advantage by doing
less copying of lists.
∂30-Dec-88 0234 CL-Cleanup-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Dec 88 02:34:03 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01499g; Fri, 30 Dec 88 02:29:35 PST
Received: by bhopal id AA13596g; Fri, 30 Dec 88 02:31:41 PST
Date: Fri, 30 Dec 88 02:31:41 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812301031.AA13596@bhopal>
To: Gray@DSG.csc.ti.com
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: David N Gray's message of Thu, 29 Dec 88 20:23:51 CST <2808440631-7583328@Kelvin>
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
re: I ran all of the test cases on an Explorer and found that the results were
all consistent with proposal
BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:INTERCHANGEABLE . . .
It's highly probably that all "spiritual descendents" of MacLisp have
this behaviour, because they all probably copied the optimization that
treats ",." ",@" and ".," the same when found at the penultimate
position of a list. ["backquote" evolved during the mid-1970's at
MIT in the AI and LCS labs].
Steele's book was the first to formalize the meaning of backquote, with
his meta-language on p.350. From this discussion, it is clear that
the step
(APPEND ... (APPEND X NIL)) ==> (APPEND ... X)
is arbitrary, rather than being an inevitable part of the intended
meaning. Steele implies that either doing this optimization or not
doing it is fine. But the Issue APPEND-DOTTED now seems to make
this an invalid optimization.
My feeling is that we either have to go for the discriminatory version
of BACKQUOTE-COMMA-ATSIGN-DOT-COMMA -- the one that says that ".," and
",@" really don't produce the same code -- or else we have to go back
to the prior state for APPEND.
-- JonL --
∂30-Dec-88 1425 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Dec 88 14:25:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513668; Fri 30-Dec-88 17:24:15 EST
Date: Fri, 30 Dec 88 17:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881129165233.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881230222336.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree with REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE as I think it
would be modified by ensuing discussion (be more careful in the
discussion of whether new objects are consed or not, and putting in the
missing functions SORT, STABLE-SORT, MERGE, and NSUBLIS; will there be a
version 5?), except that there is one additional change you need to
make:
Where you say
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
you also need to say that it is an error after this operation to
reference any CONS that was formerly part of the top-level list
structure and is no longer part of it. Of course this applies not
just to REMF, but also to SETF of GETF, NREVERSE, DELETE,
DELETE-DUPLICATES, NCONC, NUNION, NINTERSECTION, NSET-EXCLUSIVE-OR,
SORT, STABLE-SORT, and MERGE and to the ones that are defined to be
equivalent to these; these are all the ones that might change
list structure rather than just replacing CAR elements.
You see, not only are these destructive functions allowed to change
the components of the conses that make up the top-level list structure
of the argument, they are also allowed to reuse the storage of those
conses for something else that isn't a cons at all. You may recall
that this was DLA's original motivation for bringing up the issue.
I strongly disagree with Larry's contention that SETF of GETF, REMF,
SETF of GET, and REMPROP are not reasonable to include in this proposal.
If anything, the property list operators have less justification for the
user to depend on the representation than (for example) DELETE, not more
justification.
I disagree with JonL's and Larry's contention that NBUTLAST is not
reasonable to include in this proposal. I think it would be reasonable
to implement NBUTLAST by sliding all the list elements to the right n
positions and then returning NTHCDR n of the original list. However,
CLtL p.271 could be interpreted as -requiring- NBUTLAST to be
implemented in terms of RPLACD of a specific cons, rather than just
mentioning that as an example; if so, I would change my mind and
agree that NBUTLAST should be excluded from this proposal.
I also believe that NCONC (and hence by implication NRECONC) is
reasonable to optimize, but on that point I could easily be swayed to
change my mind since I can't think of any really plausible
optimizations. However, CLtL doesn't offer much evidence that a
specific implementation of NCONC is required.
For the others Larry listed (NSUBST, NSUBST-IF, and NSUBST-IF-NOT), what
the proposal actually says ("is permitted to SETF any part of the TREE
of conses which must be replaced by NEW-OBJECT.") is not proposing to
allow an implementation to modify any portion of a cons other than what
CLtL requires it to modify. Perhaps that means there is no reason to
include these in the proposal because the proposal says exactly the same
thing about these that CLtL says. BTW CLtL appears to -require- a
side-effect for these rather than merely -allowing- a side-effect.
∂30-Dec-88 1432 CL-Cleanup-mailer Issue SPECIAL-TYPE-SHADOWING (V1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Dec 88 14:32:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513671; Fri 30-Dec-88 17:31:08 EST
Date: Fri, 30 Dec 88 17:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue SPECIAL-TYPE-SHADOWING (V1)
To: David N Gray <Gray@DSG.csc.ti.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <2803680321-5692691@Kelvin>
Message-ID: <19881230223036.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
SPECIAL-TYPE-SHADOWING:CLARIFY seems right (i.e. the most consistent
with the rest of Common Lisp as it is emerging).
∂30-Dec-88 1446 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Dec 88 14:45:54 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513680; Fri 30-Dec-88 17:43:47 EST
Date: Fri, 30 Dec 88 17:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
To: Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810072119.AA03303@mist.UUCP>
Message-ID: <19881230224313.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I don't have any record of this issue being discussed. If I'm
coming in late, please ignore and forgive me.
Date: Fri, 07 Oct 88 17:19:22 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
References: Array type specifiers, pp. 45-46
Related issues: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, DECLARE-TYPE-FREE
I don't think this has any actual interactions with the issue
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, since
DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES is about ARRAY type specifiers for
declaration, while ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS is about ARRAY type
specifiers for discrimination.
Category: CLARIFICATION
Edit history: Version 1, 7-Oct-88, Pierson
Problem description:
Array type specifiers appear to be useful both for declaring the
storage format of the array and for declaring the types of legal
operations on array elements. Unfortunately, the current definition
of the meaning of array type specifiers does not require an
implementation to support the second use.
Proposal (DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE):
Within the scope of an array type declaration, all references to array
elements are assumed to satisfy the exact declared element type.
That's reasonable. However, this is not a CLARIFICATION but a CHANGE,
since CLtL p.46 seems to be quite clear that the current meaning of such
a TYPE declaration is that the array elements satisfy the implementation
element type (what JonL calls the upgraded type), not the exact declared
element type. Since your proposed new definition is more restrictive,
some portable programs that used to be correct may now be in error, hence
this is an incompatible CHANGE. I think I'd vote for it anyway unless
someone argues that there is a significant impact on users.
An
implementation should signal an error if this is ever violated.
That's not reasonable. The status quo for type declarations is that
a violation "is an error". Changing it to "signals an error" is likely to
meet enormous resistance especially from stock hardware implementations,
and I think even changing it to "signals an error at the highest SAFETY
setting" would meet significant resistance.
A
compiler may treat the code within the scope of the array type
declaration as if each access of an array element was surrounded by an
appropriate THE form.
That's a good way to define it (except you shouldn't assume that letting
everyone work out for themselves what the "appropriate THE form" is means
they will all come up with the same answer!).
Examples:
(DEFVAR *ONE-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 5)))
(DEFVAR *ANOTHER-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 8)))
(DEFUN FROB (AN-ARRAY)
(DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
(SETF (AREF AN-ARRAY 1) 31) ; OK
(SETF (AREF AN-ARRAY 2) 127) ; Should signal an error
(SETF (AREF AN-ARRAY 3) (* 2 (AREF AN-ARRAY 3))) ; Run-time decision needed
(LET ((FOO 0))
(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
(SETF FOO (AREF AN-ARRAY 0)))) ; Declared to be safe
(FROB *ONE-ARRAY*) ; Legal call, should signal an error
(FROM *ANOTHER-ARRAY*) ; Is probably an undetectable error
Note that the above definition of FROB is equivalent to:
(DEFUN FROB (AN-ARRAY)
(DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 1) 31))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 2) 127))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))
(* 2 (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))))
(LET ((FOO 0))
(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
(SETF FOO (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 0)))))
Test Cases:
TBS
Rationale:
This mandates a useful and commonly expected behavior. It complements
proposal ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, which deals with array
type specifiers as they refer to arrays as a whole. The "should
signal an error" requirement permits compiler optimization while
requiring interpreters and low compiler optimization levels to perform
useful error checking.
Current practice:
???
Cost to Implementors:
Most implementations will have to extend the type checking in the
interpreter and low optimization levels of the compiler.
Cost to Users:
Some users might find that errors in existing code become visible for
the first time.
Cost of non-adoption:
Users will continue to expect declaration syntax to be more useful
than it really is.
It will be harder to debug code that uses arrays containing
specialized types.
Performance impact:
Highly optimized code should be unaffected. Interpreted and
unoptimized code will run slower because of the additional error
checking.
Benefits:
It will be easier to use the Common Lisp type system to catch
programming errors.
Aesthetics:
Improved because the meaning of type declarations will coincide more
clearly with their appearance.
Discussion:
Pierson supports this proposal.
JonL expressed support for the idea behind this proposal during the
discussion of ARRAY-TYPE-ELEMENT-TYPE-SEMANITICS but said that it was
a compiler committee problem. This was submitted as a cleanup issue
anyway because it imposes requirements on the interpreter as well as
the compiler.
∂30-Dec-88 1525 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Dec 88 15:25:51 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513694; Fri 30-Dec-88 18:24:45 EST
Date: Fri, 30 Dec 88 18:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: COERCE-INCOMPLETE (Version 2)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881209-164733-1437@Xerox>
Message-ID: <19881230232406.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 9 Dec 88 16:47 PST
From: masinter.pa@Xerox.COM
So why don't we just define:
(coerce x 'string) == (string x)
This is the whole problem. Leaving aside the cases that are
currently required to signal an error, (string nil) => "nil"
and (coerce nil 'string) => "" are currently required by CLtL.
So one way or another this would be an incompatible change.
Maybe it would be worth the incompatible change for the
increased consistency, who knows? I don't like incompatible
changes.
(coerce x 'character) == (character x)
Already true by definition (CLtL p.241).
(coerce x 'pathname) = (pathname x)
Good idea.
(coerce x 'float) = (float x),
Already true; not by definition, but deducible from CLtL.
Also (coerce x 'rational) = (rational x) would be a good idea,
don't you think? CLtL p.52 indicates this was left out because
the user should have to decide explicitly whether to use rational
or rationalize.
The other functions that are also names of types that can be used
as type-specifiers without arguments are:
ATOM
BIT
BREAK -- condition system type
COMPLEX
CONS
ERROR -- condition system type
FUNCTION
LIST
NULL
VECTOR
except for FUNCTION, none of these is a coercer. Should
(coerce x 'function) = (eval `(function ,x))? Actually that
may have already been added to the language by the function-type
proposal, I forget.
I might think that
(coerce nil 'string) might well return a different value than
(coerce nil '(vector character)).
I think that would be a really bad idea! It's hard to be sure, but
I think CLtL's definition of COERCE very carefully skates around
any problems like this. Making (coerce x 'string) = (string x)
might introduce this problem if we're not careful.
I think I've just been led back to the same place I always end up
when thinking about COERCE, even though that's not what I expected
at all when I started this message. We should either leave COERCE
essentially the way it is or get rid of it. I appreciate Larry's
argument that it's good to have because you know a lot about what
it will do even without knowing the specific coercions for the
target type.
∂30-Dec-88 1628 CL-Cleanup-mailer Issue GC-MESSAGES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Dec 88 16:28:05 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513710; Fri 30-Dec-88 19:26:54 EST
Date: Fri, 30 Dec 88 19:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881114101307.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881231002621.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I still think that focussing on GC messages is wrong, and instead there
should be a form that disables unsolicited typeout in general,
regardless of its source. Of course in some operating systems it might
be impossible to disable some forms of unsolicited typeout, and in other
operating systems unsolicited typeout might not exist (that is,
asynchronous messages might always come out in a separate window).
Thus this facility would just do the best effort appropriate for
the particular implementation.
I think there should be a stream argument, since there might be more
than one possible place for unsolicited typeout. In other words,
(WITHOUT-UNSOLICITED-OUTPUT (<stream>) <body>...) means that the output
send by <body> to <stream> should appear as a unit, without other
unsolicited output interspersed with it.
I don't think your :VERBOSE T option to encourage unsolicited typeout
is needed.
∂30-Dec-88 1650 CL-Cleanup-mailer Issue GC-MESSAGES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Dec 88 16:50:51 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513719; Fri 30-Dec-88 19:49:42 EST
Date: Fri, 30 Dec 88 19:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 2)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19881231002621.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <881230194912.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 30 Dec 88 19:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I still think that focussing on GC messages is wrong, and instead there
should be a form that disables unsolicited typeout in general,
regardless of its source. Of course in some operating systems it might
be impossible to disable some forms of unsolicited typeout, and in other
operating systems unsolicited typeout might not exist (that is,
asynchronous messages might always come out in a separate window).
Thus this facility would just do the best effort appropriate for
the particular implementation.
I think there should be a stream argument, since there might be more
than one possible place for unsolicited typeout. In other words,
(WITHOUT-UNSOLICITED-OUTPUT (<stream>) <body>...) means that the output
send by <body> to <stream> should appear as a unit, without other
unsolicited output interspersed with it.
What if the typeout isn't going to a stream? Eg, some implementations might
cheat and do native non-stream-based I/O raw to the terminal during a GC to
avoid the risk of consing. I'm pretty sure I've seen some implementation
do this but I can't remember which.
Also, what if I do
(WITHOUT-UNSOLICITED-OUTPUT (*TERMINAL-IO*) <body>)
? Does this affect unsolicited output to *STANDARD-OUTPUT*?
Also, what if I do
(WITHOUT-UNSOLICITED-OUTPUT (*STANDARD-OUTPUT*) <body>)
? Does this affect unsolicited output to *TERMINAL-IO*?
Maybe we'd specify the stream to which unsolicited typeout is supposed to
go to help avoid problems like this. But then why would anyone bother to
use this macro on any other stream.
Without a way to test this property of a stream, no user-created stream
is going to ever respect this form anyway because unsolicited typeout
can't be distinguished from solicited typeout by the low-level printer
routines.
To my way of thinking, the root of this problem is that the system thinks
it is permissible to type on the virtual CL console. Personally, I think
this is a violation of the whole purpose of having stream-based I/O, which
is to keep the output of one program separate from the output of another.
Creating a stream-based abstraction to solve the problem of somebody
violating the heart of the stream concept does not (without further
justification) seem to me the necessarily best way to proceed.
I don't think your :VERBOSE T option to encourage unsolicited typeout
is needed.
∂31-Dec-88 1935 CL-Cleanup-mailer Issue SYNTACTIC-ENVIRONMENT-ACCESS
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 31 Dec 88 19:35:07 PST
Date: Sat 31 Dec 88 19:33:20-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue SYNTACTIC-ENVIRONMENT-ACCESS
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12458956724.23.IIM@ECLA.USC.EDU>
The issue SYNTACTIC-ENVIRONMENT-ACCESS mentions a proposal before cleanup to
add optional environment arguments to MACRO-FUNCTION and GET-SETF-METHOD. Does
anyone happen to know the status of that proposal, and did it mention any other
functions that needed environment arguments? BTW, I'd like to try to avoid
letting SYNTACTIC-ENVIRONMENT-ACCESS die of neglect. I think something like
what it proposes is pretty important. I believe Sandra said (in one of her
status messages) that Eric Benson was going to do a new writeup. Sandra, have
you heard anything from him? Do you have an address for him so I can poke
him? Is he an X3J13 member?
kab
-------
∂31-Dec-88 2001 CL-Cleanup-mailer Issue EXIT-EXTENT, v5
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 31 Dec 88 20:01:14 PST
Date: Sat 31 Dec 88 19:48:58-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue EXIT-EXTENT, v5
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12458959570.23.IIM@ECLA.USC.EDU>
MINIMAL: I don't agree with this, for reasons I have already discussed
somewhat. Basically, I feel this seriously damages the semantics of the
language, playing havoc with both UNWIND-PROTECT and the definition of
dynamic-scope.
MEDIUM: Even though the intent of this proposal is what I want, I don't believe
it is really ready for voting yet because the current proposal is poorly
written. I agree with Moon's comment that this may be hard to write in a
reasonably implementation-independent way. My intuition is based on the
nesting of forms, but I'm not sure how constraining a writup based on that
would be (though obviously somewhat, since the technique Symbolic's uses would
seem to be invalidated by acceptence of something like this proposal).
This is a hard issue. Some people feel that MINIMAL is essential because
MEDIUM is too expensive/restrictive for implementors, while other people feel
that (a cleaned up) MEDIUM is essential because MINIMAL is too
expensive/restrictive for users. Since I favor MEDIUM I would hate to see
this issue die with nothing at all being said, since that can be interpreted as
defacto MINIMAL. I don't know if I'm going to be able to find the time to
write up anything more coherent though. Part of the problem I've encountered
when I've tried to do so, is that I think this whole issue is sort of
misdirected. The problem that needs clarification isn't the extent of exits,
its the dynamic environment in which cleanup forms are executed (in spite of
the fact that the proposal says the extent of other dynamic-extent entities
should be the subject of seperate proposal(s), a claim which I totally disagree
with). UNWIND-PROTECT cleanup forms are the only place where these proposals
make a difference (to the user).
kab
-------
∂01-Jan-89 0259 CL-Cleanup-mailer *** HELP ***
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 1 Jan 89 02:59:22 PST
Date: Sat 31 Dec 88 19:35:53-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: *** HELP ***
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12458957189.23.IIM@ECLA.USC.EDU>
I don't have copies of the latest versions of some of the issues in Larry's
ballot. Would some kind person who already has them easily accessable let me
know, and I'll send a list of which issues I need.
And yes, I know they are supposed to be available via anonymous FTP from
Arisia. Repeated attempts to get them that way have failed. I keep getting
timeout and failed to synchronize transmission errors. So far, I haven't even
been able to do a dir on the directory.
Thanks in advance,
kab
-------
∂01-Jan-89 0302 CL-Cleanup-mailer Issue FIXNUM-NON-PORTABLE, v4
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 1 Jan 89 03:02:30 PST
Date: Sat 31 Dec 88 19:47:14-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue FIXNUM-NON-PORTABLE, v4
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12458959255.23.IIM@ECLA.USC.EDU>
Basically, I don't think either proposal really addresses the problem
adequately. I'm looking at this from the point of view of someone who has
dealt with porting C programs between machines with different native word
sizes, and therefor different definitions of the 'int' type. I see many of the
same kinds of problems here, and the approach being taken by these proposals
really doesn't do anything about them.
Actually, I think a case could be made in favor of a third proposal,
TOSS-FIXNUM-TOSS-BIGNUM, making it explicit that neither is portable. I'm not
planning to put this forward as a serious proposal though, since I expect it
would go over like a lead balloon for historical reasons if nothing else.
There are relatively few legitimate uses of FIXNUM in portable code, and
legislating the definition of FIXNUM in a fairly ad hoc way is not going to
improve the situation. About the only place the FIXNUM type specifier should
appear in portable code is as part of the definition of a type used by the
portable code, with the definition parameterized according to the
implementation being ported to. Even there it is probably better to use ranged
integer type specifiers.
kab
-------
∂01-Jan-89 2142 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Jan 89 21:42:26 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02548g; Sun, 1 Jan 89 21:38:03 PST
Received: by bhopal id AA21474g; Sun, 1 Jan 89 21:40:16 PST
Date: Sun, 1 Jan 89 21:40:16 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901020540.AA21474@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: pierson%mist@MULTIMAX.ARPA, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 30 Dec 88 17:43 EST <19881230224313.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
I seem to have no record of past mail on this issue, but I remember at
one time arguing against it since it tended to contradict the agreement
in ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS -- namely (1) that we wouldn't
distinguish between "for declaration" and "for discrimination", and
(2) that the original source-code element-type specifier may be "upgraded"
so that for all intents an purposes you can't recover the "exact declared
element type". But if all that Dan wanted to say was that the array
references were assumed to satisfy the *upgrade* of the declared type,
then there would be no problem (with that part).
My name probably got put reference in this proposal because I have
generally given support for the following notion: that there be at least
one mode of operation (interpretation or compilation) in which all type
information is rigidly checked. I don't think Lucid would be that averse
to some form of required error signaling in this case; but likely it
wouldn't be in interpreted code -- rather, it most easily could be in
code compiled under highest safety [because the interpreter currently
doesn't pay attention to type declarations]. Contrary to your suggestion,
I would have thought that Symbolics would offer more resistance to this
idea than would "stock hardware" implementatons, since many of the latter
have already invested in a compiler cognizant of type declartions.
-- JonL --
∂01-Jan-89 2359 CL-Cleanup-mailer Issue SYNTACTIC-ENVIRONMENT-ACCESS
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Jan 89 23:59:42 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02603g; Sun, 1 Jan 89 23:56:03 PST
Received: by bhopal id AA21788g; Sun, 1 Jan 89 23:58:15 PST
Date: Sun, 1 Jan 89 23:58:15 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901020758.AA21788@bhopal>
To: IIM@ECLA.USC.EDU
Cc: cl-cleanup@SAIL.STANFORD.EDU, cl-compikelr@SAIL.STANFORD.EDU
In-Reply-To: Kim A. Barrett's message of Sat 31 Dec 88 19:33:20-PST <12458956724.23.IIM@ECLA.USC.EDU>
Subject: Issue SYNTACTIC-ENVIRONMENT-ACCESS
Eric Benson reads the CL-Cleanup mails, and ocasionally participates
in its discussions. His address is eb@lucid.com, but he's on vacation
right now.
I think one can assume that MACRO-FUNCTION and GET-SETF-METHOD will
neeed &environment arguments. The issue for GET-SETF-METHOD was
"passed" in June 1987.
I fear that we have let MACRO-FUNCTION drop on the floor. Larry's
"Issue Status" for the Ft. Collins meeting (Nov 1987) says that
it "need[s a] volunteer" to write it up. I don't recall seeing a
subsequent proposal. It ought to be trivial.
For the record, Lucid's implementation of MACRO-FUNCTION has an
optional second argument for the &environment.
-- JonL --
∂02-Jan-89 1037 CL-Cleanup-mailer Issue: REST-LIST-ALLOCATION (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 10:36:26 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513971; Mon 2-Jan-89 13:25:47 EST
Date: Mon, 2 Jan 89 13:25 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REST-LIST-ALLOCATION (Version 3)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881213211541.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890102182514.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 13 Dec 88 21:15 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
This is a tough issue.
.... discussion elided for brevity ....
On the basis of the reasoning presented above, my position is that we
should do the following two things:
- Drop the NEWLY-ALLOCATED and MUST-SHARE variants as practically
infeasible and ramp up MAY-SHARE.
I strongly agree with this.
- Extend MAY-SHARE to include a mechanism that seriously addresses
the fact that sometimes we need to get a particular kind of
functionality. Perhaps declarations like
(REST-LIST-SHARING :NEVER)
(REST-LIST-SHARING :SOMETIMES)
(REST-LIST-SHARING :ALWAYS)
or
(REST-LIST-ALLOCATION :NEW)
(REST-LIST-ALLOCATION :UNSPECIFIC)
(REST-LIST-ALLOCATION :SHARE)
Upin reflection, I don't support this part. I can't understand why a
portable program would ever depend on (REST-LIST-SHARING :ALWAYS),
unless it's going to perform side-effects on the &rest list as a way of
passing information back to the caller. But I strongly believe that
side-effecting such a list is a really bad idea. Any program that needs
to create and modify a list should use an explicitly created list that
is passed as a normal argument, not the implicitly created list received
as an &rest argument, in my opinion. Also, as Kent pointed out there
might be implementations in which (REST-LIST-SHARING :ALWAYS) is
impossible to implement.
The other reason for using (REST-LIST-SHARING :ALWAYS) might be a belief
that it enhances efficiency. But it seems to me that if sharing was
more efficient than not sharing, the implementation would be doing it
already, and in general the implementor knows better than the PORTABLE
programmer what implementation technique for rest arguments is most
efficient.
This leaves (REST-LIST-SHARING :NEVER). The only justification for this
I can see that is that the program is going to perform side-effects on
the &rest list and wants them insulated from the caller, and furthermore
doesn't want the overhead of calling COPY-LIST in implementations that
don't share. This is certainly not as unreasonable as
(REST-LIST-SHARING :ALWAYS), but it's still pretty specialized. I have
two objections to doing this with a declaration rather than with
imperative code. First: why should
(defun foo (&rest x)
(declare (rest-list-sharing :never))
(remf x :frob)
...)
compile into different instructions than
(defun foo (&rest x)
(setq x (copy-list x))
(remf x :frob)
...)
An implementation that never shares can easily notice the redundant
call to COPY-LIST and remove it. All we need is a hint to programmers
and implementors that this is an expected optimization.
Second: declarations other than SPECIAL declarations are supposed to be
"completely optional and correct declarations do not affect the meaning
of a correct program." A declaration about rest-list-sharing that
makes it valid to perform side-effects on a rest-list clearly does not
fit this dictum of CLtL. On the other hand, if even with the declaration
it is still not correct to perform side-effects on a rest-list, then
I don't see any use for (REST-LIST-SHARING :NEVER); it can only make a
program slower.
In conclusion, REST-LIST-ALLOCATION:MAY-SHARE without additional
declarations is the only proposal that I find viable and consistent
with the rest of Common Lisp.
∂02-Jan-89 1044 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 10:44:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513967; Mon 2-Jan-89 12:37:48 EST
Date: Mon, 2 Jan 89 12:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
To: Jon L White <jonl@lucid.com>
cc: pierson%mist@MULTIMAX.ARPA, cl-cleanup@sail.stanford.edu
In-Reply-To: <8901020540.AA21474@bhopal>
Message-ID: <19890102173715.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 1 Jan 89 21:40:16 PST
From: Jon L White <jonl@lucid.com>
I seem to have no record of past mail on this issue, but I remember at
one time arguing against it since it tended to contradict the agreement
in ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS -- namely (1) that we wouldn't
distinguish between "for declaration" and "for discrimination", and
(2) that the original source-code element-type specifier may be "upgraded"
so that for all intents an purposes you can't recover the "exact declared
element type". But if all that Dan wanted to say was that the array
references were assumed to satisfy the *upgrade* of the declared type,
then there would be no problem (with that part).
I basically agree with you, but would like to point out one thing that I
hadn't thought of until I read your mail just now. Since a portable
program cannot know what the upgraded element type is, it must not
assume that all implementations have some objects that are members of
the upgraded element type but not members of the exact declared type.
This means that if it "is an error" for an array element not to be of
the upgraded type, it also "is an error" for an array element not to be
of the exact declared type; either way, a program that does that is not
portable. So the only real problem with Pierson's proposal is its
proposed change of enforcement of type declarations from "is an error"
to "signals an error".
Now, if we make it "signals an error in the highest safety mode" then
we're back with the same problem: does it signal an error when you
violate the declared type, or only when you violate the upgraded type?
The former provides a more portable definition of when errors are
signalled, but violates the consistency of declaration with
discrimination. The latter keeps declaration and descrimination
consistent, but means that there are some cases that "are an error" (or
at least are not portable) in lower safety settings, but fail to "signal
an error" in the highest safety setting.
My name probably got put reference in this proposal because I have
generally given support for the following notion: that there be at least
one mode of operation (interpretation or compilation) in which all type
information is rigidly checked. I don't think Lucid would be that averse
to some form of required error signaling in this case; but likely it
wouldn't be in interpreted code -- rather, it most easily could be in
code compiled under highest safety [because the interpreter currently
doesn't pay attention to type declarations]. Contrary to your suggestion,
I would have thought that Symbolics would offer more resistance to this
idea than would "stock hardware" implementatons, since many of the latter
have already invested in a compiler cognizant of type declartions.
I was referring to the suggestion that type information be rigidly checked
in all modes, not just in the highest safety mode. In fact it would not be
terribly difficult for Symbolics to check all type requirements, including
declarations, rather than just most implicit type requirements, in the
highest safety mode. What priority this would have for implementation
relative to other things I can't say, but I do know that keeping track of
type declarations in the compiler would not be a major part of the work.
I believe it is a one-line change, actually.
It would be interesting to see the impact of a Lucid implementation where
debugging was easier in compiled code than in interpreted code.
∂02-Jan-89 1045 CL-Cleanup-mailer *** HELP ***
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 10:45:29 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513972; Mon 2-Jan-89 13:26:59 EST
Date: Mon, 2 Jan 89 13:26 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: *** HELP ***
To: IIM@ECLA.USC.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <12458957189.23.IIM@ECLA.USC.EDU>
Message-ID: <890102132618.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Sat 31 Dec 88 19:35:53-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
I don't have copies of the latest versions of some of the issues in Larry's
ballot. Would some kind person who already has them easily accessable let me
know, and I'll send a list of which issues I need. ...
send me your list, and i'll try to get you up to date...
∂02-Jan-89 1202 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 12:02:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514009; Mon 2-Jan-89 15:00:49 EST
Date: Mon, 2 Jan 89 15:00 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881115161453.5.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<881207-180731-2393@Xerox>
Message-ID: <19890102200018.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor DYNAMIC-EXTENT:NEW-DECLARATION over STACK-LET, because
a declaration does seem more appropriate than a new special form.
I favor it over WITH-DYNAMIC-EXTENT, because (as BarMar pointed
out) saying that -all- objects consed during execution of a form
have dynamic extent is too dangerous.
However I cannot support the current version of the DYNAMIC-EXTENT
proposal, basically for the reason that Masinter gave. See below.
While I'm here I'll also comment on typos.
Date: Tue, 15 Nov 88 16:14 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Issue: DYNAMIC-EXTENT
Problem Description:
-> Sometimes a programmers knows that a particular data structure
programmer[s]
Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):
Other interesting cases are:
(PROCLAIM '(INLINE G))
(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
-> (DEFUN F () (F (LIST 1 2 3)))
The second F should be G.
What data types (if any) can be stack-allocated will vary from
implementation to implementation. In some implementations, it might be
possible to allocate arrays, structures, or instances, for example.
Masinter seems not to have noticed this paragraph, since he complained
that the proposal addressed only lists, so perhaps it should be moved
earlier in the proposal. I suggest coupling this with the second
paragraph in the proposal section, which makes it clear that the
declaration -allows- the declared object to be stack-allocated
regardless of its type, but does not -require- anything to be
stack-allocated.
The following is where I disagree strongly with the proposal:
It is very important to note that it is the actual constructor operation
and not the resulting data type which determines the level of the object
referred to in the dynamic extent declaration. For example, in
(LET ((X (LIST 'A1 'B1 'C1))
(Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
(DECLARE (DYNAMIC-EXTENT X Y))
...)
The list (A1 B1 C1) which is the initial value of X will have three cons
cells, all of which have dynamic extent. The cons (A2 . (B2 C2)) which is
the initial value of Y will have dynamic extent, but its cdr (B2 C2) will
have indefinite extent.
I think this is the wrong way to look at it in general, and furthermore
this means that backquote can't be used correctly with the
DYNAMIC-EXTENT declaration, since there is no promise what backquote
expands into. Also this way of looking at it requires saying silly (in
my opinion) things like:
If an implementation does not recognize the constructor, it calls
MACROEXPAND-1 in hopes of seeing a constructor which it does recognize.
A particular implementation might well be implemented this way, but this
should not be the definition of the language!
I propose the following instead. I admit that this is somewhat stilted,
but I think that is necessary in order to be precise and unambiguous.
The meaning of a dynamic extent declaration is that execution of the
forms in the scope of the declaration will not "save" any "proper part"
of the initial value of the declared variable. To "save" an object
means to cause a reference to that object to be accessible outside the
dynamic extent of the form at the beginning of whose body the
declaration appears. An object can be "saved" by storing it with a
side-effecting operation and not replacing it with a different value
before the end of the dynamic extent, by using it as a component of a
freshly-allocated object that is itself "saved," by capturing it in a
function closure that is itself "saved," by returning it as a value, or
by transmitting it outside the dynamic extent with THROW. A "proper
part" of an object A is any object that is accessible at the beginning
of the scope of the declaration -only- by applying a function to A or to
a "proper part" of A. This means that any objects freshly allocated
during the construction of the initial value of the declared variable,
and not "saved" during the construction of that value, are "proper
parts" and can be allocated on a stack.
Returning to the example
(LET ((X (LIST 'A1 'B1 'C1))
(Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
(DECLARE (DYNAMIC-EXTENT X Y))
...)
The "proper parts" of X are three conses, and the "proper parts" of Y
are three other conses. None of the symbols A1, B1, C1, A2, B2, C2, or
NIL is a "proper part" of X or Y. However, if a freshly allocated
uninterned symbol had been used, it would have been a "proper part."
Test Case:
(DOTIMES (I N)
(DECLARE (DYNAMIC-EXTENT I))
This is particularly instructive. Since I is an integer by the
definition of DOTIMES, but EQ and EQL are not necessarily equivalent for
integers, what are the "proper parts" of I, which this declaration
requires the body of the DOTIMES not to "save"? If the value of I is 3,
and the body does (SETQ FOO 3), is that an error? The answer is no, but
the interesting thing is that it depends on the implementation-dependent
behavior of EQ on numbers. In an implementation where EQ and EQL are
equivalent for 3, then 3 is not a "proper part" because (EQ I (+ 2 1))
is true, and therefore there is another way to access the object besides
going through I. On the other hand, in an implementation where EQ and
EQL are not equivalent for 3, then the particular 3 that is the value of
I is a "proper part", but any other 3 is not. Thus (SETQ FOO 3) is valid
but (SETQ FOO I) is erroneous. Since (SETQ FOO I) is erroneous in some
implementations, it is erroneous in all portable programs, but some other
implementations may not be able to detect the error.
I hope no one misreads the above as an argument that my proposal is too
complicated, since it does not derive at all from my proposal, but only
from the way Common Lisp works.
Discussion:
Actually, a blurry issue is whether
(LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
=> 1
is well-defined. I refer to these stack-allocated things as being invalid
return values, but in fact we might want to say that they're ok to return
but that you just can't do any serious operations on them (ie, you can't
expect them to still be lists, etc.) Can anyone imagine a pointer into
unallocated stack causing problems for their GC? If so, we could be more
clear on this point.
In some if not all implementations, the part of the stack above the
current stack pointer can have its contents changed at any time by an
interrupt, possibly to something that will cause LIST to blow out when
it stores it into the CAR of the CONS it creates. That's an
implementational point of view. From a language point of view, I do not
believe you can make a coherent definition of "serious operations." I
don't think this is a blurry issue at all, I think it's quite clear that
returning an object as a value is "saving" it regardless of what the
caller actually does with the value. I would say that even
(PROGN (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)
NIL)
is an error.
Date: 7 Dec 88 18:05 PST
From: masinter.pa@Xerox.COM
Version 2 of this writeup didn't mention one of the criticisms I sent on 1
July, namely:
"a) it is disturbing to introduce a construct within which a casual change
of (CONS X (LIST Y Z)) to (LIST X Y Z) could introduce a serious bug
(e.g., if the tail were stashed away
somewhere.)"
I quite agree with this. My proposed alternative definition doesn't have any
problems like this, since it is defined in terms of the actual object, not in
terms of how it was constructed.
I wonder if it might be useful to think about what the semantics of
declaring something to be "dynamic extent" really means.
For example, I think of a type declaration as a promise from the programmer
to the compiler that a TYPEP assertion will at certain points (exactly what
points being subject to some debate).
When you declare something as DYNAMIC-EXTENT, what is it you are promising
to the compiler? That the value of the variable or any part of it will not
be newly stored in any other permanent structure? It or any subpart of it
will not be referenced outside of the dynamic extent of the enclosing form?
My proposed alternative definition addresses this, I believe. I'd be interested
to hear if anyone can find any imprecisenesses in it.
∂02-Jan-89 1233 CL-Cleanup-mailer Issue: REST-LIST-ALLOCATION (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 12:33:16 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514015; Mon 2-Jan-89 15:32:02 EST
Date: Mon, 2 Jan 89 15:31 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REST-LIST-ALLOCATION (Version 3)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881213211541.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Supersedes: <19890102182514.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: In the previous transmission I left out part of what I had intended to say.
Message-ID: <19890102203124.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 13 Dec 88 21:15 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
This is a tough issue.
.... discussion elided for brevity ....
On the basis of the reasoning presented above, my position is that we
should do the following two things:
- Drop the NEWLY-ALLOCATED and MUST-SHARE variants as practically
infeasible and ramp up MAY-SHARE.
I strongly agree with this. MUST-SHARE is out because some implementations
cannot implement it. NEWLY-ALLOCATED is not as bad, but I want to rebut an
argument that was given in favor of it:
(defvar *message*)
(defun set-message (&rest mess)
(setq *message* mess))
(let ((winner (list 'a 'winner)))
(apply #'set-message winner)
(setf (cdr winner) (list 'loser))
winner)
Is *message* (A WINNER) or (A LOSER)? With MAY-SHARE, the answer is
implementation-dependent, with NEWLY-ALLOCATED the answer is (A WINNER).
Consider this similar program:
(defvar *message*)
(defun set-message (mess)
(setq *message* mess))
(let ((winner (list 'a 'winner)))
(funcall #'set-message winner)
(setf (cdr winner) (list 'loser))
winner)
The answer is (A LOSER).
All I did was change APPLY to FUNCALL, and remove the corresponding
&REST. I find it inconsistent if calling with APPLY is guaranteed to
copy one of the arguments, but calling with FUNCALL is not. I think
all the example shows is that programs with side-effects are generally
more difficult to understand than programs without side-effects, and
we certainly won't fix that by tweaking the definition of APPLY.
- Extend MAY-SHARE to include a mechanism that seriously addresses
the fact that sometimes we need to get a particular kind of
functionality. Perhaps declarations like
(REST-LIST-SHARING :NEVER)
(REST-LIST-SHARING :SOMETIMES)
(REST-LIST-SHARING :ALWAYS)
or
(REST-LIST-ALLOCATION :NEW)
(REST-LIST-ALLOCATION :UNSPECIFIC)
(REST-LIST-ALLOCATION :SHARE)
Upin reflection, I don't support this part. I can't understand why a
portable program would ever depend on (REST-LIST-SHARING :ALWAYS),
unless it's going to perform side-effects on the &rest list as a way of
passing information back to the caller. But I strongly believe that
side-effecting such a list is a really bad idea. Any program that needs
to create and modify a list should use an explicitly created list that
is passed as a normal argument, not the implicitly created list received
as an &rest argument, in my opinion. Also, as Kent pointed out there
might be implementations in which (REST-LIST-SHARING :ALWAYS) is
impossible to implement.
The other reason for using (REST-LIST-SHARING :ALWAYS) might be a belief
that it enhances efficiency. But it seems to me that if sharing was
more efficient than not sharing, the implementation would be doing it
already, and in general the implementor knows better than the PORTABLE
programmer what implementation technique for rest arguments is most
efficient.
This leaves (REST-LIST-SHARING :NEVER). The only justification for this
I can see that is that the program is going to perform side-effects on
the &rest list and wants them insulated from the caller, and furthermore
doesn't want the overhead of calling COPY-LIST in implementations that
don't share. This is certainly not as unreasonable as
(REST-LIST-SHARING :ALWAYS), but it's still pretty specialized. I have
two objections to doing this with a declaration rather than with
imperative code. First: why should
(defun foo (&rest x)
(declare (rest-list-sharing :never))
(remf x :frob)
...)
compile into different instructions than
(defun foo (&rest x)
(setq x (copy-list x))
(remf x :frob)
...)
An implementation that never shares can easily notice the redundant
call to COPY-LIST and remove it. All we need is a hint to programmers
and implementors that this is an expected optimization.
Second: declarations other than SPECIAL declarations are supposed to be
"completely optional and correct declarations do not affect the meaning
of a correct program." A declaration about rest-list-sharing that
makes it valid to perform side-effects on a rest-list clearly does not
fit this dictum of CLtL. On the other hand, if even with the declaration
it is still not correct to perform side-effects on a rest-list, then
I don't see any use for (REST-LIST-SHARING :NEVER); it can only make a
program slower.
In conclusion, REST-LIST-ALLOCATION:MAY-SHARE without additional
declarations is the only proposal that I find viable and consistent
with the rest of Common Lisp.
∂02-Jan-89 1328 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 13:28:15 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 514035; 2 Jan 89 16:26:46 EST
Date: Mon, 2 Jan 89 16:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 1)
To: CL-Cleanup@sail.stanford.edu
cc: Common-Lisp-Object-System@Sail.Stanford.edu, CL-Compiler@Sail.Stanford.edu
In-Reply-To: <19881229175913.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890102212611.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
This was discussed on the clos and compiler lists. I thought it would
be a good idea to write it up for discussion and give the cleanup group
a look at it. I think it's something that fell in the cracks between
these three subcommittees.
Issue: LOAD-OBJECTS
References: none
Related issues: none
Category: ADDITION
Edit history: Version 1, 2-Jan-89, by Moon (for discussion)
Problem description:
Common Lisp doesn't provide any way to use an object of a user-defined
type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program
compiled with COMPILE-FILE. The problem is that LOAD has to be able
to "reconstruct" an equivalent object when the compiled-code file is
loaded, but the programmer has no way to tell LOAD how to do that.
Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM):
Define a new generic function named MAKE-LOAD-FORM, which takes one
argument and returns one value. The value is a form which, when
evaluated at some later time, should return an object that is
equivalent to the argument. The exact meaning of "equivalent"
depends on the type of object and is up to the programmer who
defines a method for MAKE-LOAD-FORM.
Define that COMPILE-FILE calls MAKE-LOAD-FORM on any object that
appears in a constant and has STANDARD-CLASS or STRUCTURE-CLASS as a
metaclass. Define that COMPILE-FILE will only call MAKE-LOAD-FORM
once for any given object (compared with EQ) within a single file.
It is unspecified whether LOAD calls EVAL on the form or does some
other operation that has an equivalent effect.
Define that an instance of a class defined with DEFCLASS without any
direct superclasses, or defined with DEFSTRUCT without the :TYPE or
:INCLUDE options, does not inherit any method for MAKE-LOAD-FORM other
than possibly a method that only signals an error.
Example:
(defclass my-class ()
((a :initarg :a :reader my-a)
(b :initarg :b :reader my-b)
(c :accessor my-c)))
(defmethod shared-initialize ((self my-class) ignore &rest ignore)
(unless (slot-boundp self 'c)
(setf (my-c self) (some-computation (my-a self) (my-b self)))))
(defmethod make-load-form ((self my-class))
`(make-instance ',(class-name (class-of self))
:a ',(my-a self) :b ',(my-b self)))
In this example, an equivalent instance of my-class is reconstructed
by using the values of two of its slots. The value of the third slot
is derived from those two values.
(defclass my-frob ()
((name :initarg :name :reader my-name)))
(defmethod make-load-form ((self my-frob))
`(find-my-frob ',(my-name self) :if-does-not-exist :create))
In this example, instances of my-frob are "interned" in some way.
An equivalent instance is reconstructed by using the value of the
name slot as a key for searching existing objects. In this case
the programmer has chosen to create a new object if no existing
object is found; alternatively she could have chosen to signal an
error in that case.
Rationale:
Only the programmer who designed a class can know the correct
way to reconstruct objects of that class at load time, therefore
the reconstruction should be controlled by a generic function.
Using EVAL as the interface for telling LOAD what to do provides
full generality.
A default method, such as one that makes an object whose class has the
same name and whose slots have equivalent contents, is not supplied
because this is inappropriate for many objects and because it is easy
to write for those objects where it is appropriate.
MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT.
Current practice:
Symbolics Flavors has something like this, but under a different name.
The name Symbolics uses is not suitable for standardization.
JonL reports that Lucid is getting more and more requests for this.
Cost to Implementors:
This seems like only a few one-line changes in the compiled-code
file writer and reader.
Cost to Users:
None.
Cost of non-adoption:
Serious impairment of the ability to use extended-type objects. Each
implementation will probably make up its own version of this as an
extension.
Performance impact:
None.
Benefits:
See Cost of non-adoption.
Esthetics:
No significant positive or negative impact.
Discussion:
It would be possible to define an additional level of protocol that
allows multiple classes to contribute to the reconstruction of an
object, combining initialization arguments contributed by each class.
Since a user can easily define that in terms of MAKE-LOAD-FORM without
modifying the Lisp system, it is not being proposed now.
Any type that has a read syntax is likely to appear as a quoted
constant or inside a quoted constant. Pathnames are one example, user
programs often define others. Also many implementations provide a way
to create a compiled-code file full of data (rather than compiled Lisp
programs), and such data probably include extended-type objects.
Moon supports this.
∂02-Jan-89 1444 CL-Cleanup-mailer [Kim A. Barrett <IIM@ECLA.USC.EDU>: Ballot reply]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 14:44:02 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 14:42:54 PST
Date: 2 Jan 89 14:42 PST
From: masinter.pa@Xerox.COM
Subject: [Kim A. Barrett <IIM@ECLA.USC.EDU>: Ballot reply]
To: cl-cleanup@sail.stanford.edu
Message-ID: <890102-144254-1696@Xerox>
Hi -- I'm reading answering the volumes of mail I have in a fairly random
order, so things will come out of sync.
Some ballots came in only to me, so I'm forwarding them to the entire
committee, and will prepare a summary/status report.
----- Begin Forwarded Messages -----
Return-Path: <IIM@ECLA.USC.EDU>
Received: from ECLA.USC.EDU ([26.21.0.65]) by Xerox.COM ; 01 JAN 89
05:11:50 PST
Date: Sat, 31 Dec 88 19:53:52 PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Ballot reply
To: masinter.pa
cc: iim@ECLA.USC.EDU
Message-ID: <12458960461.23.IIM@ECLA.USC.EDU>
Larry,
Here is my response to the cleanup ballot. This can be considered the
'official' position of IIM. I've included extensive comments on a few
issues.
I consider some of these issues controversial, and not appropriate to a
block
vote. I've commented on some of them as to why I think they have problems.
I'm going to send these comments out for general distribution so that
people
can respond, but I'm also including them here to help you tell which ones
I'm
just voting yes/no on and which ones I think need further work or should be
voted separately.
I have not voted on the following issues because I don't have a copy of the
current proposal to read. If I can obtain copies of them in time I'll send
a
seperate response for just them. Yes, I know about /clcleanup/pending on
arisia, but repeated FTP attempts haven't gotten me anywhere.
kab
===============================================================================
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
DECLARE-TYPE-FREE:ALLOW
FUNCTION-DEFINITION:FUNCTION-SOURCE
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
HASH-TABLE-TESTS:ADD-EQUALP
LAMBDA-FORM:NEW-MACRO
LCM-NO-ARGUMENTS:1
LISP-SYMBOL-REDEFINITION:DISALLOW
NTH-VALUE:ADD
PACKAGE-DELETION:NEW-FUNCTION
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
RETURN-VALUES-UNSPECIFIED:SPECIFY
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
SETF-PLACES:ADD-SETF-FUNCTIONS
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
SYMBOL-MACROLET-DECLARE:ALLOW
TAGBODY-CONTENTS:FORBID-EXTENSION
TEST-NOT-IF-NOT:FLUSH-ALL
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
===============================================================================
And now for the voting ...
===============================================================================
ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
YES
===============================================================================
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
YES
===============================================================================
DECLARATION-SCOPE:NO-HOISTING
DECLARATION-SCOPE:LIMITED-HOISTING
Version 4, 15-Nov-88, Mailed 9-Dec-88
NO on both proposals.
I really don't like NO-HOISTING because it is too imcompatible. I think I
could live with LIMITED-HOISTING, but I'm unconvinced of the need for such
an
incompatible change. All of the problem examples are easily solved by
simply
changing some of the variable names.
===============================================================================
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
YES
===============================================================================
DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
YES
===============================================================================
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
While I support the concept, the wording needs cleanup. If these problems
are
fixed, then I'll vote YES.
1. The proposal explicitely says to allow &OPTIONAL, &KEY, and &AUX
keywords,
but fails to mention &REST and &ALLOW-OTHER-KEYS.
2. The proposal does not say how defaulting is to be done when the
programmer
doesn't supply a default value for a keyword argument. I assume that the
intent is that it will do defaulting in the same way &OPTIONAL arguments
are
specified to default in CLtL, ie. if no default is supplied in the
lambda-list
then use the slot initform, else undefined.
3. The proposal does not say which of key/var gets matched to the slot name
in
keyword parameter specifiers of the form ((key var) [default [svar]]). I
assume that it should be var that gets matched, since that gives the
programmer
the most options, but this needs to be stated explicitely.
Note for Current Practice: The latest version of IIM Common Lisp
implements
this.
===============================================================================
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
YES
===============================================================================
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
YES
===============================================================================
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
DESCRIBE-INTERACTIVE:NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
EXPLICITLY-VAGUE: ABSTAIN
NO: YES
I sort of agree with the arguments for disallowing interaction, but I won't
be
too upset if the NO proposal gets shot down and we have to go to
EXPLICTLY-VAGUE.
===============================================================================
DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
YES
===============================================================================
EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
I thought this had been pretty well hashed out, so I was surprised to find
some
serious problems with the proposal. While I support the general idea of
the
proposal, I can't vote in favor of it in its current form. If these things
get
cleaned up, then I'll vote YES. Note that all of my problems with the
current
proposal have to do with EQUALP; I agree with the proposal for EQUAL, and
would
vote YES for it as a seperate issue if the EQUALP stuff can't be resolved
in
time.
1. The description of EQUALP's behavior does not match CLtL, since it
references EQUAL more than it ought. Specifically, characters should be
compared with CHAR-EQUAL, and numbers should be compared with =, while the
proposal says EQL for numbers (by defaulting to EQUAL) and is ambiguous
about
characters (could be EQL (by defaulting to EQUAL) or CHAR-EQUAL (since
string
comparisons are case insensitive)).
2. The proposal says EQUALP descends arrays, structures, and instances, but
uses EQ on other types, and gives hash-tables as an example of a data type
which is not descended. What if, in a given implementation, hash-tables
are
implemented using structures or instances. Does this mean that such an
implementation must include code in EQUALP to explicitely prevent
descending
into hash-tables (and presumably any other COMMON types which are
implemented
using structures or instances)? This question has to be answered if the
use of
EQUALP is to have any chance of being portable when applied to such
objects.
===============================================================================
EXIT-EXTENT:MINIMAL
EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
MINIMAL: NO, for reasons I have discussed on the mailing list. Basically,
I
feel this seriously damages the semantics of the language, playing havoc
with
both UNWIND-PROTECT and the definition of dynamic-scope.
MEDIUM: Currently NO, even though the intent of this proposal is what I
want,
because the current proposal is poorly written. I don't believe it is
really
ready for voting yet. I agree with Moon's comment that this may be hard to
write in a reasonably implementation-independent way. My intuition is
based on
the nesting of forms, but I'm not sure how constraining a writup based on
that
would be (though obviously somewhat, since the technique Symbolic's uses is
invalidated by acceptence of something like this proposal).
===============================================================================
EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
YES
===============================================================================
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Version 4, 7-Dec-88, Mailed 12-Dec-88
NO on both.
Basically, I don't think either proposal really addresses the problem
adequately. I'm looking at this from the point of view of someone who has
dealt with porting C programs between machines with different native word
sizes, and therefor different definitions of the 'int' type. I see many of
the
same kinds of problems here, and the approach being taken by these
proposals
really doesn't do anything about them.
Actually, I think a case could be made in favor of a third proposal,
TOSS-FIXNUM-TOSS-BIGNUM, making it explicit that neither is portable. I'm
not
planning to put this forward as a serious proposal though, since I expect
it
would go over like a lead balloon for historical reasons if nothing else.
There are relatively few legitimate uses of FIXNUM in portable code, and
legislating the definition of FIXNUM in a fairly ad hoc way is not going to
improve the situation. About the only place the FIXNUM type specifier
should
appear in portable code is as part of the definition of a type used by the
portable code, with the definition parameterized according to the
implementation being ported to. Even there it is probably better to use
ranged
integer type specifiers.
===============================================================================
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
YES
===============================================================================
FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
YES
===============================================================================
FUNCTION-COMPOSITION:NEW-FUNCTIONS
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
NEW-FUNCTIONS: NO. I agree with some of the discussion that this is an
inadequate set of operators, it is untested by the community, and serves no
visible need. Encourage people to add extensions like this, and we'll see
what
results when we do CL9x (or CL2001).
COMPLEMENT-AND-ALWAYS: YES. I can see COMPLEMENT being a useful standard
shorthand that makes the removal of the :test-not and -if-not stuff more
palatable.
===============================================================================
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
YES
===============================================================================
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
NO
===============================================================================
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
YES.
There is a minor glitch in an aside that needs to be fixed. Paragraph 3 of
item 3 says that the following code would be acceptable as the <sxh>
function
for EQL tables:
(if (numberp x) (sxhash x) (%unique-no x))
In general, the NUMBERP test really should be (OR (NUMBERP X) (CHARACTERP
X)),
to correspond properly to the definition of EQL.
===============================================================================
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
YES
===============================================================================
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
NO
===============================================================================
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
YES
===============================================================================
PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
YES, but note such that symbols which are documented special-forms are also
FBOUNDP.
===============================================================================
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
YES
However, I think it should be mentioned that this implies that PEEK-CHAR is
really no longer equivelent to read-char followed by unread-char, and can't
be
implemented that way for any kind of metastream. All metastreams must now
support PEEK-CHAR directly, and pass it along to the indirect streams, in
case
some of those streams are echo streams. This mostly increases the cost to
implementors, though it is also a cost to users in systems where the set of
metastreams is user-extensible.
===============================================================================
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
YES
===============================================================================
PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
===============================================================================
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
YES
===============================================================================
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
YES
===============================================================================
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
REST-LIST-ALLOCATION:MAY-SHARE
REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
NEWLY-ALLOCATED: NO
MUST-SHARE: NO
I feel that both of these take away too much implementation freedom. Which
leaves us with ...
MAY-SHARE: YES.
But I'd like to see something added that allows the programmer to force
copying
when she cares, without requiring an explicit call to COPY-LIST (possibly
featurized). Note that most cases of COPY-LIST on &REST parameters that
I've
seen had nothing to do with the question of whether apply => &rest could
share;
they were put in to deal with implementations which always stack-cons &rest
lists.
===============================================================================
ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
YES
I liked KMP's suggestion of defining additional synonyms:
:short == nil
:medium == :default
:long == t
This could be done as a seperate proposal, but hardly seems worth the
effort.
===============================================================================
SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
YES
===============================================================================
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
YES
===============================================================================
STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
I have no problem with TIME behaving as proposed. I have serious problems
with
STEP though, as far as compiled behavior. I don't agree that it is easy to
get
the environment right in this case, because it would require the
interpreter to
handle compiler data structures, which might not even be possible. Maybe
I'm
misunderstanding what is wanted for compiled STEP. If what is wanted is
that
execution of interpreted code which occurs within the context of the STEP
macro
should be stepped, then that's ok, and I'll vote YES.
===============================================================================
SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
YES
===============================================================================
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
YES
===============================================================================
TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
YES
===============================================================================
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
YES, assuming bugs are fixed. Include Moon's phrasing of the constraint I
brought up: (SUBTYPEP (TYPE-OF X) (CLASS-OF X)) => T T, for all X.
===============================================================================
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
YES
-------
----- End Forwarded Messages -----
∂02-Jan-89 1455 CL-Cleanup-mailer re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 14:54:57 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 14:53:09 PST
Date: 2 Jan 89 14:52 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-145309-1706@Xerox>
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
While I support the concept, the wording needs cleanup. If these problems are
fixed, then I'll vote YES.
1. The proposal explicitely says to allow &OPTIONAL, &KEY, and &AUX keywords,
but fails to mention &REST and &ALLOW-OTHER-KEYS.
2. The proposal does not say how defaulting is to be done when the programmer
doesn't supply a default value for a keyword argument. I assume that the
intent is that it will do defaulting in the same way &OPTIONAL arguments are
specified to default in CLtL, ie. if no default is supplied in the lambda-list
then use the slot initform, else undefined.
3. The proposal does not say which of key/var gets matched to the slot name in
keyword parameter specifiers of the form ((key var) [default [svar]]). I
assume that it should be var that gets matched, since that gives the programmer
the most options, but this needs to be stated explicitely.
Note for Current Practice: The latest version of IIM Common Lisp implements
this.
∂02-Jan-89 1517 CL-Cleanup-mailer re: Issue: EQUAL-STRUCTURE (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 15:17:11 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:16:05 PST
Date: 2 Jan 89 15:15 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: EQUAL-STRUCTURE (Version 5)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-151605-1724@Xerox>
I thought this had been pretty well hashed out, so I was surprised to find some
serious problems with the proposal. While I support the general idea of the
proposal, I can't vote in favor of it in its current form. If these things get
cleaned up, then I'll vote YES. Note that all of my problems with the current
proposal have to do with EQUALP; I agree with the proposal for EQUAL, and would
vote YES for it as a seperate issue if the EQUALP stuff can't be resolved in
time.
1. The description of EQUALP's behavior does not match CLtL, since it
references EQUAL more than it ought. Specifically, characters should be
compared with CHAR-EQUAL, and numbers should be compared with =, while the
proposal says EQL for numbers (by defaulting to EQUAL) and is ambiguous about
characters (could be EQL (by defaulting to EQUAL) or CHAR-EQUAL (since string
comparisons are case insensitive)).
2. The proposal says EQUALP descends arrays, structures, and instances, but
uses EQ on other types, and gives hash-tables as an example of a data type
which is not descended. What if, in a given implementation, hash-tables are
implemented using structures or instances. Does this mean that such an
implementation must include code in EQUALP to explicitely prevent descending
into hash-tables (and presumably any other COMMON types which are implemented
using structures or instances)? This question has to be answered if the use of
EQUALP is to have any chance of being portable when applied to such objects.
∂02-Jan-89 1517 CL-Cleanup-mailer re: Issue: EXIT-EXTENT (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 15:17:47 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:16:42 PST
Date: 2 Jan 89 15:16 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: EXIT-EXTENT (Version 5)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-151642-1725@Xerox>
MINIMAL: NO, for reasons I have discussed on the mailing list. Basically, I
feel this seriously damages the semantics of the language, playing havoc with
both UNWIND-PROTECT and the definition of dynamic-scope.
MEDIUM: Currently NO, even though the intent of this proposal is what I want,
because the current proposal is poorly written. I don't believe it is really
ready for voting yet. I agree with Moon's comment that this may be hard to
write in a reasonably implementation-independent way. My intuition is based on
the nesting of forms, but I'm not sure how constraining a writup based on that
would be (though obviously somewhat, since the technique Symbolic's uses is
invalidated by acceptence of something like this proposal).
∂02-Jan-89 1521 CL-Cleanup-mailer re: Issue: EXIT-EXTENT (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 15:21:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:17:30 PST
Date: 2 Jan 89 15:16 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: EXIT-EXTENT (Version 5)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-151730-1728@Xerox>
MINIMAL: NO, for reasons I have discussed on the mailing list. Basically, I
feel this seriously damages the semantics of the language, playing havoc with
both UNWIND-PROTECT and the definition of dynamic-scope.
MEDIUM: Currently NO, even though the intent of this proposal is what I want,
because the current proposal is poorly written. I don't believe it is really
ready for voting yet. I agree with Moon's comment that this may be hard to
write in a reasonably implementation-independent way. My intuition is based on
the nesting of forms, but I'm not sure how constraining a writup based on that
would be (though obviously somewhat, since the technique Symbolic's uses is
invalidated by acceptence of something like this proposal).
∂02-Jan-89 1521 CL-Cleanup-mailer re: Issue: FIXNUM-NON-PORTABLE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 15:21:42 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:18:16 PST
Date: 2 Jan 89 15:17 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: FIXNUM-NON-PORTABLE (Version 4)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-151816-1730@Xerox>
NO on both.
Basically, I don't think either proposal really addresses the problem
adequately. I'm looking at this from the point of view of someone who has
dealt with porting C programs between machines with different native word
sizes, and therefor different definitions of the 'int' type. I see many of the
same kinds of problems here, and the approach being taken by these proposals
really doesn't do anything about them.
Actually, I think a case could be made in favor of a third proposal,
TOSS-FIXNUM-TOSS-BIGNUM, making it explicit that neither is portable. I'm not
planning to put this forward as a serious proposal though, since I expect it
would go over like a lead balloon for historical reasons if nothing else.
There are relatively few legitimate uses of FIXNUM in portable code, and
legislating the definition of FIXNUM in a fairly ad hoc way is not going to
improve the situation. About the only place the FIXNUM type specifier should
appear in portable code is as part of the definition of a type used by the
portable code, with the definition parameterized according to the
implementation being ported to. Even there it is probably better to use ranged
integer type specifiers.
∂02-Jan-89 1524 CL-Cleanup-mailer re: Issue: PACKAGE-CLUTTER:REDUCE (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 15:24:32 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:22:33 PST
Date: 2 Jan 89 15:22 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: PACKAGE-CLUTTER:REDUCE (Version 6)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-152233-1735@Xerox>
YES, but note such that symbols which are documented special-forms are also
FBOUNDP.
∂02-Jan-89 1525 CL-Cleanup-mailer re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 15:24:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:23:48 PST
Date: 2 Jan 89 15:23 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-152348-1739@Xerox>
However, I think it should be mentioned that this implies that PEEK-CHAR is
really no longer equivelent to read-char followed by unread-char, and can't be
implemented that way for any kind of metastream. All metastreams must now
support PEEK-CHAR directly, and pass it along to the indirect streams, in case
some of those streams are echo streams. This mostly increases the cost to
implementors, though it is also a cost to users in systems where the set of
metastreams is user-extensible.
∂02-Jan-89 1524 CL-Cleanup-mailer re: Issue: HASH-TABLE-STABILITY (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 15:24:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:21:01 PST
Date: 2 Jan 89 15:20 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: HASH-TABLE-STABILITY (Version 1)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-152101-1732@Xerox>
There is a minor glitch in an aside that needs to be fixed. Paragraph 3 of
item 3 says that the following code would be acceptable as the <sxh> function
for EQL tables:
(if (numberp x) (sxhash x) (%unique-no x))
In general, the NUMBERP test really should be (OR (NUMBERP X) (CHARACTERP X)),
to correspond properly to the definition of EQL.
∂02-Jan-89 1528 CL-Cleanup-mailer re: Issue: REST-LIST-ALLOCATION (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 15:27:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:26:43 PST
Date: 2 Jan 89 15:25 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: REST-LIST-ALLOCATION (Version 3)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-152643-1745@Xerox>
NEWLY-ALLOCATED: NO
MUST-SHARE: NO
I feel that both of these take away too much implementation freedom. Which
leaves us with ...
MAY-SHARE: YES.
But I'd like to see something added that allows the programmer to force copying
when she cares, without requiring an explicit call to COPY-LIST (possibly
featurized). Note that most cases of COPY-LIST on &REST parameters that I've
seen had nothing to do with the question of whether apply => &rest could share;
they were put in to deal with implementations which always stack-cons &rest
lists.
∂02-Jan-89 1529 CL-Cleanup-mailer re: Issue: STEP-ENVIRONMENT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 15:29:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:28:10 PST
Date: 2 Jan 89 15:27 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: STEP-ENVIRONMENT (Version 3)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-152810-1747@Xerox>
I have no problem with TIME behaving as proposed. I have serious problems with
STEP though, as far as compiled behavior. I don't agree that it is easy to get
the environment right in this case, because it would require the interpreter to
handle compiler data structures, which might not even be possible. Maybe I'm
misunderstanding what is wanted for compiled STEP. If what is wanted is that
execution of interpreted code which occurs within the context of the STEP macro
should be stepped, then that's ok, and I'll vote YES.
∂02-Jan-89 1635 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 16:34:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514100; Mon 2-Jan-89 19:33:29 EST
Date: Mon, 2 Jan 89 19:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890103003245.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
There was considerable discussion about the released version 8 not
reflecting the concensus of the committee. I don't feel strongly about
this either way, but as an aid in discussion I have prepared this
version, which contains two proposals.
The argument is about whether a type declaration affects only variable
references within its scope, or also affects variable references that
are outside the scope of the declaration but dynamically inside the
execution of a form that is itself inside the scope of the declaration.
This really has nothing to do with the original goal of the proposal,
since exactly the same issue arises for a type declaration attached
to a binding of a special variable.
Forum: Cleanup
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Related issues: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
DECLARATION-SCOPE
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Version 5, 30-Sep-88, Masinter (cost to implementors)
Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
Version 7, 5-Dec-88, Masinter (scope->extent)
Version 8, 7-Dec-88, Masinter (back to scope)
Version 9, 2-Jan-89, Moon (2 proposals, to clarify discussion)
Problem description:
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
any effect:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
(incf y)
...random algorithm...))
Proposal (DECLARE-TYPE-FREE:ALLOW):
Specify that a type declaration does not only "affect variable bindings";
rather, type declarations are legal in all declarations. The interpretation
of a type declaration is that, during the execution of any expression
within the scope of the declaration, it is an error for the value of
the declared variable not to be of the declared type. For declarations
that are associated with variable bindings, the type declaration also
applies to the initial binding of the variable. In the special case
of a declaration for which there are no executable expressions
within the scope of the declaration (e.g., (locally (declare (integer x)))),
the result is as if there were executable expressions.
In this proposal, a type declaration affects not only variable
references within its scope, but also affects variable references that
are outside the scope of the declaration but dynamically inside the
execution of a form that is itself inside the scope of the
declaration. Such references can exist when the variable is SPECIAL
or when the declaration is not attached to the variable's binding, so
that the scope of the declaration does not include the entire scope
of the variable.
Proposal (DECLARE-TYPE-FREE:LEXICAL):
Specify that a type declaration does not only "affect variable bindings";
rather, type declarations are legal in all declarations. The interpretation
of a type declaration is that, during the execution of any reference to the
declared variable within the scope of the declaration, it is an error for
the value of the declared variable not to be of the declared type; and
during the execution of any SETQ of the declared variable within the scope
of the declaration, it is an error for the newly assigned value of the
declared variable not to be of the declared type; and at the moment the
scope of the declaration is entered, it is an error for the value of the
declared variable not to be of the declared type.
In this proposal, a type declaration affects only variable references within
its scope, and the meaning of "free" and "variable-binding-associated" type
declarations can be described identically.
This proposal is equivalent to saying that the meaning of a type declaration
is equivalent to changing each reference to <var> within the scope of the
declaration to (THE <type> <var>), changing each expression assigned to the
variable within the scope of the declaration to (THE <type> <new-value>),
and executing (THE <type> <var>) at the moment the scope of the declaration
is entered.
Examples:
;; this is an error under DECLARE-TYPE-FREE:ALLOW:
;; the assertion that x is a fixnum is violated between the two
;; calls to (zap)
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(zap)
x)))
;; this is an error under both proposals
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(print x)
(zap)
x)))
;; this is an error under DECLARE-TYPE-FREE:ALLOW, because
;; the assertion that x is a fixnum
;; is violated during the call to zap, even though few
;; implementations will be able to check:
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL
(let ((x 12) (y 'foo))
(flet ((zap ()
(rotatef x y)
(rotatef x y)))
(locally (declare (fixnum x))
(zap)
x)))
;; this is an error under both proposals, even though the
;; violation of the type constraint happens after the form
;; with the declaration is exited.
(let ((f (let ((x 3))
(declare (fixnum x))
#'(lambda (z) (incf x z)))))
(funcall f 4.3))
Rationale:
This proposal enables optimizing compilers to make use of the otherwise
ignored type information. Many people have often asked for it, and
there is no strong reason to forbid it.
DECLARE-TYPE-FREE:ALLOW is more restrictive on programs and hence allows
more freedom for optimizing compilers. DECLARE-TYPE-FREE:LEXICAL is easier
to understand but allows a specialized representation only where the scope
of the variable is the same as the scope of the declaration or the compiler
can prove that there are no relevant other references to the variable.
Current practice:
Lucid Common Lisp allows "free" type declarations; under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
Implementations that might currently warn about such declarations
would have to remove the warning; otherwise, it is valid to ignore
type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
every reference.
Esthetics:
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
language.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
Documentation might want to discuss the style implications of
nested declarations intersecting. The interesting cases are:
- An inner declaration could be a subtype of an outer one.
This is the most useful case and probably the only one to
be encouraged in code written by humans. e.g.,
(locally (declare (type number x))
(locally (declare (type integer x))
...use X as integer...))
- An outer declaration could be a subtype of an inner one.
This is useless but harmless. It might happen as the result
of certain macro situations. e.g.,
(locally (declare (type integer x))
(locally (declare (type number x))
...use X as integer...))
- Two types may only partially overlap. This would presumably
happen only as the result of a macro expansion.
(locally (declare (type fixnum x))
(locally (declare (type (or bit package) x))
...use X as BIT...))
∂02-Jan-89 1737 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 2 Jan 89 17:36:40 PST
Date: Mon 2 Jan 89 17:31:11-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12459458774.4.IIM@ECLA.USC.EDU>
Ok, since a volunteer was needed, here goes. I've also included a proposal for
SUBTYPEP, since it has similar problems. There may be other functions that
need this same treatment. CONSTANTP comes to mind, though I've decided to wait
on that until some of the issues regarding DEFCONSTANT settle down. A
VARIABLE-SPECIAL-P predicate would also need this, though that could be handled
right from the start, and can be written portably using the functional
interface defined in SYNTACTIC-ENVIRONMENT-ACCESS (assuming it makes some
progress).
kab
-----
Issue: MACRO-FUNCTION-ENVIRONMENT
References: Macros, CLtL p.143
CLOS Ch. 1 & 2
-- tbd --
Category: CHANGE
Edit history: 02-Jan-89, Version 1, by kab
Related issues: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
SYNTACTIC-ENVIRONMENT-ACCESS
Status: For Internal Discussion
Problem Description:
CLtL is often read to imply that COMPILE-FILE should avoid modifying the
behavior of the running system by changing definitions to correspond to those
in the file being compiled. Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
makes this an explicit requirement, and specifies the kind of side-effects
each of the standard defining forms is required to perform.
Implementing this distinction between the compile-time and run-time
environments requires some mechanism for distinguishing which environment is
being dealt with. MACRO-FUNCTION needs to be able to make this distinction in
order to correctly determine what value to return.
Because CLOS specifies that FIND-CLASS uses an &environment argument to make
this distinction, integration of the type system and the class system requires
that SUBTYPEP also accept an &environment argument, if for no other reason
than to be able to pass it to FIND-CLASS.
Some implementations may have already implemented some parts of these
proposals, but user code which makes use of these changes is currently not
portable.
Proposal (MACRO-FUNCTION-ENVIRONMENT:NEW-ARGUMENT)
Extend MACRO-FUNCTION to accept an optional second argument. This argument
should be either NIL, the &environment argument received by a macro expander
function, or the environment argument received by an *evalhook* or *applyhook*
function. This argument is used to distinguish between compile-time and
run-time environments.
This proposal explicitly does not modify MACRO-FUNCTION to examine the
environment argument for local definitions. MACRO-FUNCTION only returns
a symbol's global macro definition (if present).
SETF of MACRO-FUNCTION is changed such that it only sets the global macro
definition in the specified environment. Thus, if a compiler environment is
specified then the macro definition of the running system is not modified.
Proposal (SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT)
Extend SUBTYPEP to accept an optional third argument. This argument should be
either NIL, the &environment argument received by a macro expander function,
or the environment argument received by an *evalhook* or *applyhook* function.
This argument is used to distinguish between compile-time and run-time
environments.
Rationale:
CLOS already specifies the use of &environment arguments for the purpose used
here. These proposals make use of that existing facility to fix some other
functions which need the same capabilities.
Test Case:
-- tbd --
Current Practice:
Lucid's implementation of MACRO-FUNCTION has an optional second argument for
the &environment. Whether it only returns global expanders or also returns
local (macrolet) is unknown to this author.
IIM Common Lisp generally uses the &environment argument for distinguishing
between compile-time and run-time environments, but for these two functions
(whose arguments were already specified by CLtL) they implement the
discrimination through the use of a special variable.
Cost to Implementors:
These proposals require the compiler environment be distinguishable, but that
seems to already be required by CLOS. Modifying the definitions of
MACRO-FUNCTION and its SETF is probably trivial in most implementations.
Probably the modifications for SUBTYPEP are also trivial. The hard part may
be ensuring that all calls are passing the environment argument, which in most
cases will be a simple word-processing exercise, but in some cases might be
more difficult because the environment has not been passed along to the point
where it is needed.
Cost to Users:
Users must ensure that all calls are passing the proper environment argument,
which entails the same difficulties as for implementors.
Benefits:
-- tbd -- ;I didn't want to write just "Fixes the stated problem."
Aesthetics:
-- tbd -- ;I didn't want to write just "Removes a problem from the language."
Discussion:
This is yet another case of a fairly widespread problem relating to the
interaction between the compiler and the running system. There seems to be
general agreement that using a special variable to solve this class of
problems is wrong, though several implementations currently use this
technique. The designers of CLOS apparently believe so, and have specified
several of the functions in the CLOS interface as accepting an optional
&environment argument in order to solve the problem of distinguishing between
compile-time and run-time environments. Some members of the compiler
subcommittee also seem to be adopting the use of &environment arguments into
their thinking about how top-level defining forms perform their special
compile-time magic, though with some misgivings.
The decision to not have MACRO-FUNCTION examine the environment argument for
local definitions is based in part on the assumption that the issue
SYNTACTIC-ENVIRONMENT-ACCESS (SEA) will make some progress. MACRO-FUNCTION is
generally used as a predicate or as a place for SETF (the return value is
probably almost never used outside of the implementation of MACROEXPAND), and
SEA proposes a mechanism for determining the presence of a local definition
and for adding local macro definitions to an environment.
SUBTYPEP really needs this change regardless of CLOS, for the same reasons
that MACRO-FUNCTION does. The demands of CLOS simply make it more immediately
obvious.
The extension of allowing an environment argument from *evalhook* or
*applyhook* functions seems reasonable, though it might be inferable from the
acceptence of &environment arguments. However, since CLtL specifically states
that the &environment argument need not be a complete lexical environment,
this could be arguable. Rather than leaving such a question open for debate,
this proposal makes explicit allowance for such values. If it is agreed that
this explicitness is necessary, then CLOS should ammended appropriately too.
-------
∂02-Jan-89 1811 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 18:11:20 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 415645; Mon 2-Jan-89 21:10:49 EST
Date: Mon, 2 Jan 89 21:09 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19890103003245.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890102210923.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
My strong preference is for LEXICAL. The ALLOW proposal (which is the
only option offered in v8, which is on the ballot) doesn't sit well
with me, and I wouldn't have been inclined vote yes on it.
Btw, both versions 8 and 9 have the non-preemptive problem that the
only examples they provide illustrate what happens in the screw
cases. This might lead some people to think that this whole issue
is kind of random. I think there should be a few examples of the
"normal use" (such as the un-filled-out examples in the problem
description). It's probably worth fixing this before the meeting
so that people doing last-minute aren't bogged down trying to decipher
the proposal by working backward from the strange examples currently
in the proposal.
∂02-Jan-89 1820 CL-Cleanup-mailer Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 18:20:11 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 JAN 89 18:19:06 PST
Date: Mon, 02 Jan 89 18:18:58 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
In-reply-to: <19881229201656.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
To: CL-Cleanup@SAIL.Stanford.Edu
Cc: Pavel.pa@Xerox.COM
Message-ID: <890102-181906-1853@Xerox>
David says, ``ASSERT ... properly only allow[s] single values.''
Why do you think so? I assume that you disagree with my reasoning in
response to GSB:
``In the case of ASSERT it is NOT a list of individual values, but of
individual PLACES. Sure they can be individually changed by the user. But
doesn't that user specify an expression whose value will be stored? Can't
that expression return multiple values?''
Where do we disagree?
Pavel
∂02-Jan-89 1821 CL-Cleanup-mailer Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 18:21:49 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 JAN 89 18:20:45 PST
Date: Mon, 02 Jan 89 18:20:37 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
In-reply-to: <19881229201656.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
To: CL-Cleanup@SAIL.Stanford.Edu
Cc: Pavel.pa@Xerox.COM
Message-ID: <890102-182045-1856@Xerox>
Oops, I forgot to answer David's other question:
``Do you plan to bring an updated version of this proposal
to the next X3J13 meeting?''
I won't be at that meeting, so I'll just send another copy to this mailing list.
Pavel
∂02-Jan-89 1836 CL-Cleanup-mailer Issues: SINGLE-FLOAT-NON-PORTABLE,
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 18:36:08 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 18:33:56 PST
Date: 2 Jan 89 18:33 PST
From: masinter.pa@Xerox.COM
Subject: Issues: SINGLE-FLOAT-NON-PORTABLE,
LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION
to: cl-cleanup@sail.stanford.edu
Message-ID: <890102-183356-1861@Xerox>
Do any of you have any desire to tangle with these?
In cleaning out my files, I came across this bit of discussion, which
raises at least two issues: SINGLE-FLOAT-NON-PORTABLE
should single-float and double-float be removed from the standard?
LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION
should LEAST-POSITIVE- and MOST-POSITIVE- numbers include denormalized ones
in those implementations that admit them?
----- Begin Forwarded Messages -----
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 08 APR 88 22:44:38 PDT
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Apr 88
22:42:47 PDT
Received: by labrea.Stanford.EDU; Fri, 8 Apr 88 21:42:13 PST
Received: from bhopal.lucid.com by edsel id AA10628g; Fri, 8 Apr 88
22:35:20 PDT
Received: by bhopal id AA08201g; Fri, 8 Apr 88 22:36:11 PDT
Date: Fri, 8 Apr 88 22:36:11 PDT
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8804090536.AA08201@bhopal.lucid.com>
To: chapman%lisp.DEC@decwrl.dec.com
Cc: edsel!jonl@labrea.Stanford.EDU, cl-cleanup@sail.stanford.edu
In-Reply-To: chapman%lisp.DEC@decwrl.dec.com's message of Fri, 8 Apr 88
07:23:21 PDT <8804081423.AA17359@decwrl.dec.com>
Subject: floating point questions
re: Dick reviewed my snapshot draft of the standard and suggested I talk to
you
about floating point number representation. . . . Do you have other
thoughts on how floating point data types should be
specified/implemented?
I don't see any clean-up proposals that have to do with this topic,
just
the LEAST-POSITIVE-<mumble>-FLOAT communication.
There are three problems of concern that I know about:
First, for purposes of CLOS, it is very inconvenient to have sub-range
types for any numerical type. In one sense, the short-float, single-float,
double-float, and long-float types are sub-ranges of float; and the thorny
issue is that that there are three possible variations one how they are
merged. I don't know how to solve this one, except by ignoring the
existence of differing float types [and there is probably at least one or
two manufactures who will fight that to the hilt, since they have optimized
one extreme end or the other and perhaps see this distinction as a
"competitive edge"]. I *could* make a case for having only FLOAT as a
Common Lisp type, leaving to the vendors the issue of foisting distinctions
off on to the user [since in many cases, the distinctions will be
irrelevant].
Very briefly, the three main points of this case are
(1) As a standard, CLtL p16-17 guarantees virtually nothing about what
single-float, double-float etc. mean; in one implementation, single
could mean a 23-bit mantissa, and in another it could mean a 96-bit
mantissa. Hence there is no guarantee of portability, so why bother?
(2) A recent survey of some numerical analysts, in a company dedicated
to selling Fortran engines, discovered the all-too-obvious fact that
many many algorithms are numerically unstable when run under the IEEE
32-bit format, but are quite well-behaved under the 64-bit format;
but interestingly, it turned up *no* cases of ill behaviour in the
64-bit mode that were correctible by going to a 128 bit format.
[Now, this is not the same as an "ill conditioned" problem]. In short,
there is a "good enough" size -- larger isn't needed, and smaller
could be justified only ocasionally by savings in space and/or time.
(3) On most machines, there seems to be a "preferred" format. In fact,
I'm aware of some hardware where single-float operations are a tad
slower than double-float ones; the driving motivation is that the
numerical analysts wanted the fastest possible floating point of
"good enough" size, and the other sizes were supported only for
"compatibility". Also, compact representations inside arrays
provide the only intesting space savings; this is quite analogous
to packed arrays of integers [e.g., an array element-type of
(signed-byte 8)]
[Since a larger group is being cc'd, I'd like to appeal to that group *not*
to flood the mailing list with lots of trivial counterexamples to each of
the above generalizations. I'm sure they've all been thought of before;
and since the status quo will remain until an actual proposal is made,
there is no need to argue against a non-proposal. If anyone would like
to contact me privately about pursuing such a proposal, I will respond;
but so far, I haven't seen much interest].
Second, some implementations permit "extremals" to be representable
numbers,
and others don't; e.g., the IEEE standard allows for "denormalized" and
"infinity" numbers, while VAX and IBM/370 don't. So the question arises
as to just what "least-positive-<mumble>-float" means; is it the smallest
possible representation, or is it the smallest "normal" representation?
Paul Hilfinger (at Berkeley) feels rather strongly that is should be
the smallest possible representation; but now that raises the issue that
on some implementatons, "least-positive-<mumble>-float" is a perfectly
normal number causing no exceptions whatsoever, while on others it will
cause an "underflow" type trap whenever it is produced (unless you turn
off trapping, and yes, "gradual underflow" really is "underflow"). About
the best consensus I could get was to follow Symbolics lead and add the
names "least-positive-normalized-<mumble>-float", so that there would be a
portable way of dealing with the smallest reasonable number. Also:
(eql least-positive-<mumble>-float
least-positive-normalized-<mumble>-float)
could be used as a test to determine whether or not the implementation
supports denormalized numbers.
A possible third trouble is with "most-positive-<mumble>-float" -- should
this be the largest reasonable number, or the largest possible
representation?
If the latter, then in the IEEE format, the positive infinity should be
"most-positive-<mumble>-float" since it certainly is larger than any other
float. By analogy with the difference between "least-positive-..." and
"least-positive-normalized-...", I would have liked to see
"most-positive-..."
and "most-positive-normalized-..."; that way, the test
(= most-positive-<mumble>-float most-positive-normalized-<mumble>-float)
could be used to determine whether or not the implementation supports
infinities. But alas, I couldn't convince QUUX (Guy Steele) about this
one,
so I'm not sure it's worth wasting any more time over.
-- JonL --
----- End Forwarded Messages -----
----- End Forwarded Messages -----
∂02-Jan-89 1852 CL-Cleanup-mailer Re: Issue: TAILP-NIL (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 18:51:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 18:50:54 PST
Date: 2 Jan 89 18:50 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TAILP-NIL (Version 5)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 13 Dec 88 19:05 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890102-185054-1879@Xerox>
For the record, re: whether the following sentence is Irrelevant,
Inflammatory, Unfounded, Shooting in the Dark
<< It was suggested more than once by more than one cleanup
committee member that we remove TAILP from the language
"since almost nobody uses it". >>
It is relevant, since it is an alternate solution to the proposal.
It is inflammatory, evidenced by your flame.
It is not unfounded; I have two messages, one from Moon and one from JonL,
that mention removing TAILP from the language as a serious possibility,
although only one of them used the phrase "since almost nobody uses it".
Perhaps you could search through your local sources for calls to TAILP?
As for "shooting in the dark", that's likely.
However, we did not go so far as to present the proposal of removing TAILP
as a serious contender, because we realized the cost of incompatible
changes. I think if I were designing a good lisp from scratch I might put
TAILP low in the list of priorities of things to add, but taking it out has
high cost and almost no benefit.
Your two suggestions (expand the proposal to deal with LDIFF, possibly add
a :TEST argument) may have gotten lost.
∂02-Jan-89 1916 CL-Cleanup-mailer Re: Issue: REST-LIST-ALLOCATION (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 19:16:23 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 19:15:18 PST
Date: 2 Jan 89 19:14 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REST-LIST-ALLOCATION (Version 3)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 13 Dec 88 21:15 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
Message-ID: <890102-191518-1893@Xerox>
re: "The only issue then would be whether there were implementations where
the always-share functionality would be impossible to implement"
In the Medley implementation of Common Lisp (and in all the Interlisp
implementations I'm familiar with), APPLY always "spreads" its arguments on
the stack, independent of the internal argument structure of the recipient
function; an &REST argument is always "consed" from the stack structure. In
this implementation, always-share would require APPLY to "look ahead"
somehow, and invoke some kind of alternate version of the function which
could take the rest list "shared".
Re "Perhaps declarations like...."
I am opposed to adding declarations that change the behavior of correct
programs. Except for SPECIAL, declarations change only the "checking" for
incorrect programs and not the behavior of correct programs.
∂02-Jan-89 2102 CL-Cleanup-mailer Re: Issue: PATHNAME-PRINT-READ (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 21:02:16 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 21:00:45 PST
Date: 2 Jan 89 21:00 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-PRINT-READ (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 21 Oct 88 17:00 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890102-210045-1930@Xerox>
For Current Practice, Envos Medley prints pathnames with the syntax #.(pathname "asdf").
I like #P"asdf" better, but #.(pathname string) is currently pretty portable.
∂02-Jan-89 2109 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL ?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 21:09:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 21:08:14 PST
Date: 2 Jan 89 21:07 PST
From: masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-LOGICAL ?
In-reply-to: Eric Benson <eb@lucid.com>'s message of Fri, 21 Oct 88
14:13:50 pdt
To: Eric Benson <eb@lucid.com>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890102-210814-1939@Xerox>
Re: "I wish someone would make a proposal
for generic pathnames. I don't think they ever got the consideration
they deserved."
There are several issues waiting a "pathname" committee to study them
further. They include:
PATHNAME-COMPONENT-CASE, PATHNAME-LOGICAL, PATHNAME-SUBDIRECTORY-LIST,
PATHNAME-SYNTAX-ERROR-TIME, PATHNAME-WILD, STREAM-CAPABILITIES,
TRUENAME-SYNTAX-ONLY
Frankly, I don't know what "generic" pathnames are, so I don't know how I
could have considered them. Are they the same thing as "logical" pathnames?
∂02-Jan-89 2118 CL-Cleanup-mailer Re: issue COMPILE-ARGUMENT-PROBLEMS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 21:17:47 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514161; Tue 3-Jan-89 00:15:34 EST
Date: Tue, 3 Jan 89 00:14 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue COMPILE-ARGUMENT-PROBLEMS
To: sandra%defun@cs.utah.edu
cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8901030502.AA05326@defun.utah.edu>
Message-ID: <890103001457.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
I had forgotten the issue was voted on.
I do, however, think there are substantial benefits to be gained from my
new proposal over the other one. I think any definition of COMPILE which
permits it to err at random (which is pretty much how I feel about all
these "is an error" situations) severely cripples the usefulness of COMPILE
in really portable code. Signalling an error rather than quietly returning
seems useless. The only reason I can think of to signal an error in general
is if there was some danger to be avoided or more than one way you could
go and you want to allow user intervention. In this case, I think people
always do just one thing: say to themselves "oh, i guess I won't compile
this". We might as well let the system do it for them.
So my inclination is to say yes, that we should reopen the issue.
My understanding was that the primary justification of the previous proposal
over this one is that it was what you thought was the "best that could be
hoped for". My inclination is to believe that this raises the least common
denominator without crossing that line where we get bogged down in
capabilities of particular implementations, etc.
Does you (or does anyone) have reason to believe that the new proposal
I've just circulated would cause any kind of problem?
∂02-Jan-89 2118 CL-Cleanup-mailer Re: issue COMPILE-ARGUMENT-PROBLEMS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 21:18:36 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 514163; 3 Jan 89 00:17:18 EST
Date: Tue, 3 Jan 89 00:16 EST
From: KMP@STONY-BROOK.SCRC.Symbolics.COM
To: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: issue COMPILE-ARGUMENT-PROBLEMS
References: <890103001457.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890103001640.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
[The referenced message has been redirected:
Sorry. I sent that message to the wrong list.
CL-Cleanup@SAIL.Stanford.EDU has been removed;
CL-Compiler@SAIL.Stanford.EDU has been added.]
∂02-Jan-89 2127 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 5)
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 21:27:05 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 305264; Tue 3-Jan-89 00:25:14 EST
Date: Tue, 3 Jan 89 00:25 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAGBODY-CONTENTS (Version 5)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <890103002508.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Typo (extra word in "the given a tag") in para 1 of Proposal.
The term "data element" is too vague in para 2 of Proposal.
These should be fixed before final vote; the latter could lead to
serious confusion.
∂02-Jan-89 2210 CL-Cleanup-mailer Re: issue COMPILE-ARGUMENT-PROBLEMS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Jan 89 22:07:33 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA06581; Mon, 2 Jan 89 23:04:23 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA05373; Mon, 2 Jan 89 23:03:11 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901030603.AA05373@defun.utah.edu>
Date: Mon, 2 Jan 89 23:03:10 MST
Subject: Re: issue COMPILE-ARGUMENT-PROBLEMS
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: sandra%defun@cs.utah.edu, CL-Cleanup@SAIL.Stanford.EDU,
KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 3 Jan 89 00:14 EST
It looks to me like the main difference between the two proposals is
in the treatment of functions defined in a non-null lexical
environment. The proposal that was voted on was amended in accordance
with your earlier suggestions to make the other situations harmless --
doing nothing is an acceptable alternative if the function is already
compiled, but signalling errors or blowing fuses is not -- so I think
the other issues you touch upon in your new proposal could probably be
handled as editorial changes. I would much rather do that than re-open
the issue (I think our time would be better spent trying to deal with
the many other unresolved issues we still have pending), but if you
feel strongly about this then of course we can go ahead and ask for
another vote.
A problem I have with your proposal is that I believe that
COMPILED-FUNCTION-P must be true of any function returned from
COMPILE, and that COMPILE must also at least ensure that all macro
calls in the function have been expanded. I don't think that allowing
COMPILE to do nothing when passed an interpreted function is a
legitimate option.
I've actually been trying to draft a short document for Kathy Chapman
to describe the minimum functionality required for implementations of
COMPILE and COMPILE-FILE (incorporating Steve's famous "compiler
model" from last March), but if what's obvious to me isn't obvious to
other people, I should probably turn at least this one part of the
writeup into a new issue so we can vote on it formally.
-Sandra
-------
∂02-Jan-89 2214 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 22:14:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 22:13:15 PST
Date: 2 Jan 89 22:12 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 2 Jan 89 19:32 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <890102-221315-1967@Xerox>
Thanks for doing this, I think it does help clarify the discussion.
I had thought -- apparently incorrectly -- that the only objection to
making type declarations have the strongest possible meaning was the
difficulty in specifying what that meaning might be. I think the ALLOW
proposal does so consistently.
If I say (DECLARE (TYPE (SIGNED-BYTE 12) X)), I'd think I'd like it to mean
that X never even momentarily holds a value that isn't of the declared
type.
I'd suggest adding to Current Practice that some Common Lisp
implementations ignore type declarations completely.
I'd like to see the writeup make it clear that the following is subsumed;
note that this issue never was released or appeared on a Status list, so it
should probably just be included
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 04 NOV 88
16:21:08 PST
Received: from ti.com by SAIL.Stanford.EDU with TCP; 4 Nov 88 16:19:26 PST
Received: by ti.com id AA07547; Fri, 4 Nov 88 18:19:48 CST
Received: from Kelvin by tilde id AA15412; Fri, 4 Nov 88 18:03:33 CST
Message-Id: <2803680321-5692691@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 4 Nov 88 18:05:21 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SPECIAL-TYPE-SHADOWING (V1)
In-Reply-To: Msg of 28 Sep 88 20:44 PDT from masinter.pa@Xerox.COM
Issue: SPECIAL-TYPE-SHADOWING
References: CLtL pages 156, 158
Related issues: DECLARE-TYPE-FREE
Category: CLARIFICATION
Edit history: Version 1, 04-Nov-88 by David Gray
Problem description:
A Common Lisp user raised the question of whether something like the
following is legal:
(PROCLAIM '(TYPE NUMBER *X*))
(DEFVAR *X*)
(DEFUN FOO ()
(LET ((*X* T))
(DECLARE (TYPE SYMBOL *X*))
(BAR)))
Page 156 of CLtL says that a proclamation is "always in force unless
locally shadowed" and page 158 says type declarations "only affect
variable bindings", which might be interpreted to mean that the DECLARE
locally shadows the PROCLAIM. However, that interpretation would make
the global type proclamation useless because it could not be relied on
when compiling a function such as BAR.
Proposal SPECIAL-TYPE-SHADOWING:CLARIFY
Clarify that if there is a local type declaration for a special
variable, and there is also a global type proclamation for that same
variable, then the value of the variable within the scope of the local
declaration must be a member of the intersection of the two declared
types.
Rationale:
Some restriction on local type declarations for special variables is
needed in order for type proclamations to be meaningful. The wording
used here was chosen for consistency with proposal DECLARE-TYPE-FREE.
Current practice:
The TI, Symbolics, and Lucid implementations do not report any error
on the example above, but it isn't clear that they really do anything
with type declarations for special variables anyway.
Cost to Implementors:
This is unlikely to require a change in any current implementation.
Cost to Users:
Anyone who has written code like the example above would have to
modify it if compilers started enforcing this restriction.
Cost of non-adoption:
A minor ambiguity in the language specification that could confuse
users.
Performance impact:
None.
Benefits:
A clearer definition of the meaning of type declarations for special
variables.
Discussion:
This is obviously very closely related to issue DECLARE-TYPE-FREE, but
this is an ambiguity in the existing language that should be resolved
even if the language extension of proposal DECLARE-TYPE-FREE is not
accepted. Note also that DECLARE-TYPE-FREE makes no mention of type
proclamations.
Other possible resolutions of the ambiguity would be to either rule
out use of local type declarations for special variables, or to say
that the local type must be a subtype of the global type.
∂02-Jan-89 2225 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 22:25:12 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 22:24:08 PST
Date: 2 Jan 89 22:23 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 10 Nov 88 13:33 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890102-222408-1971@Xerox>
I think this is fine, too. If I were being picky I'd want some minor
cosmetic changes, but I don't think we have time.
∂02-Jan-89 2236 CL-Cleanup-mailer Re: Issue: DELETE-FILE-NONEXISTENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89 22:36:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 22:32:31 PST
Date: 2 Jan 89 22:31 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DELETE-FILE-NONEXISTENT (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Sun, 13 Nov 88 18:32 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890102-223231-1974@Xerox>
I renamed this from DELETE-NONEXISTENT-FILE.
I agree that I don't like the proposal. I'd like DELETE-FILE to spell out
what the classes of errors it would get when the file didn't exist vs when
the file couldn't be deleted.
Did you have those on your list of error signals?
∂02-Jan-89 2248 CL-Cleanup-mailer Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 22:48:03 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514178; Tue 3-Jan-89 01:46:49 EST
Date: Tue, 3 Jan 89 01:46 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881208-111031-3954@Xerox>
Message-ID: <890103014612.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
I have a problem with version 2 because I don't think anything requires
get-dispatch-macro-character to return the same function on successive
calls even with the same readtable (provided the functions returned are
equivalent). As such, the example is inappropriate where it uses ASSERT
and EQ.
∂03-Jan-89 0027 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
Received: from VALLECITO.SCRC.Symbolics.COM (SCRC-VALLECITO.ARPA) by SAIL.Stanford.EDU with TCP; 3 Jan 89 00:26:59 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 267616; Tue 3-Jan-89 01:32:47 EST
Date: Tue, 3 Jan 89 01:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
To: masinter.pa@Xerox.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <890102-221315-1967@Xerox>
Message-ID: <890103013157.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 2 Jan 89 22:12 PST
From: masinter.pa@Xerox.COM
...
If I say (DECLARE (TYPE (SIGNED-BYTE 12) X)), I'd think I'd like it to mean
that X never even momentarily holds a value that isn't of the declared
type.
...
The problems I have with this are the following:
- It isn't enforceable.
- In exactly those cases where it is enforceable, it's useful to enforce.
In those case where it is not enforceable (the odd middle-ground cases
in the Examples), it doesn't help you any to enforce the restriction, and
it might get in your way.
Put another way: If you grant that a language could be internally
consistent, well-formed, and all that sort of thing with the LEXICAL
proposal, then why not attach a useful meaning to the middle ground case?
There are potentially useful things (mostly "patches") that you could
write that way, and even if you permit it, you don't hinder the compiler's
ability to make useful inferences.
- My general rule of thumb is that if someone says they need a feature
and someone else says they don't, that the person claiming they do need
the feature has an a priori more interesting case. As such, LEXICAL is
more interesting partly because the fact that some people don't need all
its features is not a compelling thing to me. If you could make a case for
why LEXICAL caused some actual -problem-, that would make the other case
more interesting. After all, nothing about LEXICAL prevents you personally
from meaning that "X never momentarily holds..." since that's compatible
with the meaning proposed in LEXICAL -- just as nothing about the way
false and the empty-list are treated in Lisp keeps you from meaning
that () always means the empty list (even if Lisp doesn't care).
Similarly here, LEXICAL admits both views of the universe while ALLOW
admits only one. To me, this seems unfair, since ALLOW restricts things
to lock out a view of the world, without providing any hint of a reason
for why that view of the world is an unreasonable one.
∂03-Jan-89 0542 CL-Cleanup-mailer Re: Issue: DYNAMIC-EXTENT (Version 2)
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 3 Jan 89 05:42:40 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa19261; 3 Jan 89 8:32 EST
Received: from draper.com by RELAY.CS.NET id aa29726; 3 Jan 89 8:20 EST
Date: Tue, 3 Jan 89 08:11 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: DYNAMIC-EXTENT (Version 2)
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
> From: "David A. Moon" <Moon@scrc-stony-brook.ARPA>
> Subject: Issue: DYNAMIC-EXTENT (Version 2)
> The following is where I disagree strongly with the proposal:
>
> It is very important to note that it is the actual constructor operation
> and not the resulting data type which determines the level of the object
> referred to in the dynamic extent declaration. For example, in
>
> (LET ((X (LIST 'A1 'B1 'C1))
> (Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
> (DECLARE (DYNAMIC-EXTENT X Y))
> ...)
>
> The list (A1 B1 C1) which is the initial value of X will have three cons
> cells, all of which have dynamic extent. The cons (A2 . (B2 C2)) which is
> the initial value of Y will have dynamic extent, but its cdr (B2 C2) will
> have indefinite extent.
>
> I think this is the wrong way to look at it in general, and furthermore
> this means that backquote can't be used correctly with the
> DYNAMIC-EXTENT declaration, since there is no promise what backquote
> expands into.
>
> ...
>
> (LET ((X (LIST 'A1 'B1 'C1))
> (Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
> (DECLARE (DYNAMIC-EXTENT X Y))
> ...)
>
> The "proper parts" of X are three conses, and the "proper parts" of Y
> are three other conses. None of the symbols A1, B1, C1, A2, B2, C2, or
> NIL is a "proper part" of X or Y. However, if a freshly allocated
> uninterned symbol had been used, it would have been a "proper part."
>
> Date: 7 Dec 88 18:05 PST
> From: masinter.pa@Xerox.COM
>
> Version 2 of this writeup didn't mention one of the criticisms I sent on 1
> July, namely:
>
> "a) it is disturbing to introduce a construct within which a casual change
> of (CONS X (LIST Y Z)) to (LIST X Y Z) could introduce a serious bug
> (e.g., if the tail were stashed away
> somewhere.)"
>
> I quite agree with this. My proposed alternative definition doesn't have any
> problems like this, since it is defined in terms of the actual object, not in
> terms of how it was constructed.
>
I agree strongly with the comments of Moon and Masinter. For example, in our
implementation, the compiler source-transforms calls to LIST into nested
calls to CONS. Under these circumstances, it is impossible to distinguish
between the cases in the various examples above for the purpose of determining
which conses are subject to the DYNAMIC-EXTENT constraint.
∂03-Jan-89 0758 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL ?
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 07:58:16 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03074g; Tue, 3 Jan 89 07:52:30 PST
Received: by blacksox id AA00248g; Tue, 3 Jan 89 07:54:37 pst
Date: Tue, 3 Jan 89 07:54:37 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901031554.AA00248@blacksox>
To: masinter.pa@Xerox.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 2 Jan 89 21:07 PST <890102-210814-1939@Xerox>
Subject: Issue: PATHNAME-LOGICAL ?
Date: 2 Jan 89 21:07 PST
From: masinter.pa@Xerox.COM
Re: "I wish someone would make a proposal
for generic pathnames. I don't think they ever got the consideration
they deserved."
There are several issues waiting a "pathname" committee to study them
further. They include:
PATHNAME-COMPONENT-CASE, PATHNAME-LOGICAL, PATHNAME-SUBDIRECTORY-LIST,
PATHNAME-SYNTAX-ERROR-TIME, PATHNAME-WILD, STREAM-CAPABILITIES,
TRUENAME-SYNTAX-ONLY
Frankly, I don't know what "generic" pathnames are, so I don't know how I
could have considered them. Are they the same thing as "logical" pathnames?
Yes, I meant to say logical pathnames.
∂03-Jan-89 0800 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 08:00:39 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03077g; Tue, 3 Jan 89 07:56:54 PST
Received: by blacksox id AA00251g; Tue, 3 Jan 89 07:59:11 pst
Date: Tue, 3 Jan 89 07:59:11 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901031559.AA00251@blacksox>
To: IIM@ECLA.USC.EDU
Cc: cl-cleanup@SAIL.STANFORD.EDU, iim@ECLA.USC.EDU
In-Reply-To: Kim A. Barrett's message of Mon 2 Jan 89 17:31:11-PST <12459458774.4.IIM@ECLA.USC.EDU>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
Date: Mon 2 Jan 89 17:31:11-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Current Practice:
Lucid's implementation of MACRO-FUNCTION has an optional second argument for
the &environment. Whether it only returns global expanders or also returns
local (macrolet) is unknown to this author.
Yes, MACRO-FUNCTION in Lucid CL will return a MACROLET expander as
well as a DEFMACRO expander. It also correctly handles the case of an
FLET or LABELS overriding a DEFMACRO (by returning NIL).
∂03-Jan-89 0812 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 08:12:08 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03092g; Tue, 3 Jan 89 08:08:25 PST
Received: by blacksox id AA00254g; Tue, 3 Jan 89 08:10:38 pst
Date: Tue, 3 Jan 89 08:10:38 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901031610.AA00254@blacksox>
To: IIM@ECLA.USC.EDU
Cc: cl-cleanup@SAIL.STANFORD.EDU, iim@ECLA.USC.EDU
In-Reply-To: Kim A. Barrett's message of Mon 2 Jan 89 17:31:11-PST <12459458774.4.IIM@ECLA.USC.EDU>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
Date: Mon 2 Jan 89 17:31:11-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Proposal (MACRO-FUNCTION-ENVIRONMENT:NEW-ARGUMENT)
Extend MACRO-FUNCTION to accept an optional second argument. This argument
should be either NIL, the &environment argument received by a macro expander
function, or the environment argument received by an *evalhook* or *applyhook*
function. This argument is used to distinguish between compile-time and
run-time environments.
MACRO-FUNCTION should not accept the environment argument received by
an *EVALHOOK* or *APPLYHOOK* function. (*APPLYHOOK* should not even
receive an environment argument, was there ever a cleanup issue
addressing this?) MACRO-FUNCTION is only concerned with what I have
referred to as "syntactic" environments. *EVALHOOK* environments are
a different beast entirely, they don't belong in the same category.
In fact, the status of EVALHOOK is tenuous at best. How is it
done in a compiled-only implementation?
This proposal explicitly does not modify MACRO-FUNCTION to examine the
environment argument for local definitions. MACRO-FUNCTION only returns
a symbol's global macro definition (if present).
In that case, what does MACRO-FUNCTION return when there is a MACROLET
definition visible? It must return some non-NIL value. It should be
the expansion function, to be consistent with the global case.
∂03-Jan-89 0834 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 08:33:55 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03107g; Tue, 3 Jan 89 08:29:18 PST
Received: by blacksox id AA00259g; Tue, 3 Jan 89 08:31:34 pst
Date: Tue, 3 Jan 89 08:31:34 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901031631.AA00259@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: David A. Moon's message of Mon, 2 Jan 89 15:00 EST <19890102200018.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 2)
This is very good. The definitions of "saved" and "proper part" seem
quite precise to me. It is essential to have a definition independent
of the implementation. Still, it would be useful to give at least a
sketch of how this might be implemented, since it still involves
looking for functions like CONS and LIST (and whatever backquote turns
into) about which the compiler has information.
∂03-Jan-89 0902 CL-Cleanup-mailer Re: Issue: REST-LIST-ALLOCATION (Version 3)
Received: from mist.math.uoregon.edu ([128.223.4.3]) by SAIL.Stanford.EDU with TCP; 3 Jan 89 09:02:25 PST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 3 Jan 89 09:00:06 PDT
Received: by fog.cs.uoregon.edu; Tue, 3 Jan 89 08:59:44 PDT
Date: Tue, 3 Jan 89 08:59:44 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901031659.AA06887@fog.cs.uoregon.edu>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REST-LIST-ALLOCATION (Version 3)
Moon writes of his example that:
All I did was change APPLY to FUNCALL, and remove the corresponding
&REST. I find it inconsistent if calling with APPLY is guaranteed to
copy one of the arguments, but calling with FUNCALL is not.
To my way of thinking, APPLY never copies any arguments so APPLY is
perfectly consistent with FUNCALL even if &REST lists are always
freshly consed. You see, my understanding of APPLY is that it calls
its first argument on the elements of the list that is its second
argument (or the analagous thing if you give it more than two arguments).
The arguments, therefore, are the elements of the list, not the list
itself, and so the arguments are not copied.
It is true that the list created by &REST list processing may happen to
be a copy of some existing list, possibly even a list that was once
passed to APPLY, but I don't see why APPLY should be given credit for
having made the copy.
Peace, Will
∂03-Jan-89 0916 CL-Cleanup-mailer Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 09:16:19 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA25011; Tue, 3 Jan 89 12:15:08 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA12970; Tue, 3 Jan 89 12:15:09 EST
Message-Id: <8901031715.AA12970@mist.>
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
In-Reply-To: Your message of Sun, 01 Jan 89 21:40:16 -0800.
<8901020540.AA21474@bhopal>
Date: Tue, 03 Jan 89 12:15:07 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I seem to have no record of past mail on this issue, but I remember at
one time arguing against it since it tended to contradict the agreement
in ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS -- namely (1) that we wouldn't
distinguish between "for declaration" and "for discrimination", and
(2) that the original source-code element-type specifier may be "upgraded"
so that for all intents an purposes you can't recover the "exact declared
element type". But if all that Dan wanted to say was that the array
references were assumed to satisfy the *upgrade* of the declared type,
then there would be no problem (with that part).
Sorry, but that's exactly the opposite of what I meant. If I declare
an array, FOO, to be (SIGNED-BYTE 5), within the scope of that
definition I'm saying that expect references to that array to be
equivalent to:
(THE (SIGNED-BYTE 5) (AREF FOO X))
No matter what the array was upgraded to. Upgrading should refer to the
array's physical layout and overall type, but it should not license
the FOO below to be a different type from (AREF BAR X) in FROB.
(DEFUN FROB (FOO BAR)
(DECLARE (TYPE (SIGNED-BYTE 5) FOO)
(TYPE (ARRAY (SIGNED-BYTE 5)) BAR))
...
)
My name probably got put reference in this proposal because I have
generally given support for the following notion: that there be at least
one mode of operation (interpretation or compilation) in which all type
information is rigidly checked. I don't think Lucid would be that averse
to some form of required error signaling in this case; but likely it
wouldn't be in interpreted code -- rather, it most easily could be in
code compiled under highest safety [because the interpreter currently
doesn't pay attention to type declarations]. Contrary to your suggestion,
I would have thought that Symbolics would offer more resistance to this
idea than would "stock hardware" implementatons, since many of the latter
have already invested in a compiler cognizant of type declartions.
Actually, your name got put in support because of an early message of
yours (which I finally found) in the ARRAY-ELEMENT-TYPE-SEMANTICS
discussion. I'll be happy to remove your name if we now disagree.
As I've said before, I support a strict type checking mode for all
Common Lisp compilers. However I now suspect that it's too late (and
maybe too experimental) to get in this version of the standard. I
said I'd write up a proposal for it at the cleanup meeting last
October, but was later talked out of doing so.
∂03-Jan-89 0924 CL-Cleanup-mailer Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 09:24:41 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA25203; Tue, 3 Jan 89 12:23:23 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA12979; Tue, 3 Jan 89 12:23:24 EST
Message-Id: <8901031723.AA12979@mist.>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
In-Reply-To: Your message of Mon, 02 Jan 89 12:37:00 -0500.
<19890102173715.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 03 Jan 89 12:23:23 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I basically agree with you, but would like to point out one thing that I
hadn't thought of until I read your mail just now. Since a portable
program cannot know what the upgraded element type is, it must not
assume that all implementations have some objects that are members of
the upgraded element type but not members of the exact declared type.
This means that if it "is an error" for an array element not to be of
the upgraded type, it also "is an error" for an array element not to be
of the exact declared type; either way, a program that does that is not
portable. So the only real problem with Pierson's proposal is its
proposed change of enforcement of type declarations from "is an error"
to "signals an error".
Now, if we make it "signals an error in the highest safety mode" then
we're back with the same problem: does it signal an error when you
violate the declared type, or only when you violate the upgraded type?
The former provides a more portable definition of when errors are
signalled, but violates the consistency of declaration with
discrimination. The latter keeps declaration and descrimination
consistent, but means that there are some cases that "are an error" (or
at least are not portable) in lower safety settings, but fail to "signal
an error" in the highest safety setting.
The problem is that there are logically three types of declaration in
these cases: for discrimination, for declaration, and for reference.
For declaration refers to the array as a whole. For reference refers
to references to array elements. I claim that upgrading for reference
introduces a confusing and unnecessary incompatibility between array
elements and normal variables. I also claim that there are people
writing and distributing code today who neither understand nor desire
this incompatibility.
This whole upgrading thing is a necessary hack to try an adopt an
abstract type system to a varying set of efficient implementations.
There is no reason why this hack needs to be propagated to references
to individual elements, which should follow the rules for "normal"
variables as much as possible.
∂03-Jan-89 0938 CL-Cleanup-mailer Re: Issue: REST-LIST-ALLOCATION (Version 3)
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 3 Jan 89 09:38:25 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 255261; Tue 3-Jan-89 12:37:06 EST
Date: Tue, 3 Jan 89 12:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: REST-LIST-ALLOCATION (Version 3)
To: William Clinger <will@fog.cs.uoregon.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8901031659.AA06887@fog.cs.uoregon.edu>
Message-ID: <19890103173617.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 3 Jan 89 08:59:44 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Moon writes of his example that:
All I did was change APPLY to FUNCALL, and remove the corresponding
&REST. I find it inconsistent if calling with APPLY is guaranteed to
copy one of the arguments, but calling with FUNCALL is not.
To my way of thinking, APPLY never copies any arguments so APPLY is
perfectly consistent with FUNCALL even if &REST lists are always
freshly consed. You see, my understanding of APPLY is that it calls
its first argument on the elements of the list that is its second
argument (or the analagous thing if you give it more than two arguments).
The arguments, therefore, are the elements of the list, not the list
itself, and so the arguments are not copied.
It is true that the list created by &REST list processing may happen to
be a copy of some existing list, possibly even a list that was once
passed to APPLY, but I don't see why APPLY should be given credit for
having made the copy.
Something happens in between the APPLY and the &REST. You think of it as
connected with the &REST, I think of it as connected with the APPLY, and
someone else might think of it as an independent thing not really connected
with either of them. Okay.
Peace yourself.
∂03-Jan-89 0946 CL-Cleanup-mailer Re: Issue GC-MESSAGES (Version 2)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 09:46:24 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA25413; Tue, 3 Jan 89 12:45:16 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA13066; Tue, 3 Jan 89 12:45:16 EST
Message-Id: <8901031745.AA13066@mist.>
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue GC-MESSAGES (Version 2)
Date: Tue, 03 Jan 89 12:45:14 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I still think that focussing on GC messages is wrong, and instead there
should be a form that disables unsolicited typeout in general,
regardless of its source. Of course in some operating systems it might
be impossible to disable some forms of unsolicited typeout, and in other
operating systems unsolicited typeout might not exist (that is,
asynchronous messages might always come out in a separate window).
Thus this facility would just do the best effort appropriate for
the particular implementation.
I agree in general. I further think that the cleanest way to handle
the problem is by having all such output be signalled. There is then
a well-defined, portable way for a user to intercept any desired
messages and deal with them in any way. Now that we have a condition
system, this approach seems much cleaner than another set of ad-hoc
keywords, wrapper forms, functions, etc.
This is the approach I'm pushing for compiler messages in the compiler
committee, but it doesn't seem to be getting very far.
∂03-Jan-89 0952 CL-Cleanup-mailer Re: Issue GC-MESSAGES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Jan 89 09:52:25 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514389; Tue 3-Jan-89 12:51:17 EST
Date: Tue, 3 Jan 89 12:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue GC-MESSAGES (Version 2)
To: Dan L. Pierson <pierson@mist.encore.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8901031738.AA13041@mist.>
Message-ID: <19890103175039.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 03 Jan 89 12:38:44 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I still think that focussing on GC messages is wrong, and instead there
should be a form that disables unsolicited typeout in general,
regardless of its source. Of course in some operating systems it might
be impossible to disable some forms of unsolicited typeout, and in other
operating systems unsolicited typeout might not exist (that is,
asynchronous messages might always come out in a separate window).
Thus this facility would just do the best effort appropriate for
the particular implementation.
I agree in general. I further think that the cleanest way to handle
the problem is by having all such output be signalled.
This can't work for asynchronous, unsolicited typeout. In a multiprocess
system, the cause of the condition leading to message output may not be
in a "user" process, so signalling in the originating process won't give
the user any control. Also there may be multiple "user" processes and it
may not be obvious which one should receive the signal. I shouldn't
have to tell this to someone from Encore, you must have faced all these
issues already! Also a special form that disables unsolicited typeout
during the dynamic extent of its body could interact with the operating
system to disable or defer operating-system-generated typeout, but in
most operating systems it would be much more difficult to arrange for
the operating system to signal a Lisp condition when it wants to type
something out.
It's too bad it can't work, because it certainly would be cleaner.
∂03-Jan-89 0955 CL-Cleanup-mailer Re: Issue COMPILER-DIAGNOSTICS, v7
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 09:55:07 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA25447; Tue, 3 Jan 89 12:53:56 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA13100; Tue, 3 Jan 89 12:53:57 EST
Message-Id: <8901031753.AA13100@mist.>
To: "Kim A. Barrett" <IIM@ECLA.USC.EDU>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue COMPILER-DIAGNOSTICS, v7
In-Reply-To: Your message of Sat, 31 Dec 88 19:39:52 -0800.
<12458957912.23.IIM@ECLA.USC.EDU>
Date: Tue, 03 Jan 89 12:53:55 EST
From: Dan L. Pierson <pierson@mist.encore.com>
> I agree. I lumped ALERT and NOTICE together to keep them from causing
> BREAKs.
This doesn't seem necessary, with the depreciation of
*break-on-warnings* in the current condition system, being
replaced by *break-on-signals*
That may actually make things worse, depending on whether you believe
that a MEMBER type specifier is a valid portable value for
*BREAK-ON-SIGNALS*. If it isn't, you need to be able to collect all
the things you'd like to turn off as subtypes of the same type.
∂03-Jan-89 1020 CL-Cleanup-mailer Re: Issue: PATHNAME-EXTENSIONS (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 10:20:28 PST
Received: by ti.com id AA18762; Tue, 3 Jan 89 12:19:51 CST
Received: from dsg by tilde id AA14868; Tue, 3 Jan 89 12:15:51 CST
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 3 Jan 89 12:16:29 CST
Message-Id: <2808843406-15267619@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 3 Jan 89 12:16:46 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-EXTENSIONS (Version 1)
In-Reply-To: Msg of Wed, 28 Dec 88 15:57 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> Clarify that COMMON-PATHNAME-P considers a pathname's host field
> to fit the Common Lisp pathname model if the filler of the host
> field is a string (naming a host), and not otherwise.
... etc.
Rather than talk about the "fields" of a pathname, I think it would be
better to talk about the value returned by the standard accessor
functions. For example, in proposal PATHNAME-SUBDIRECTORY-LIST, you
suggested that an implementation could use a non-standard representation
internally so long as the function PATHNAME-DIRECTORY returned the
standard representation. Thus, we could say:
Clarify that COMMON-PATHNAME-P returns true if PATHNAME-HOST will
return a string, and NIL if PATHNAME-HOST will return something else.
etc.
∂03-Jan-89 1056 CL-Cleanup-mailer Re: Issue COMPILER-DIAGNOSTICS, v7
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 10:56:10 PST
Received: from [73.0.0.15] by multimax.encore.com (5.59/25-eef)
id AA25868; Tue, 3 Jan 89 13:54:55 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA13187; Tue, 3 Jan 89 13:54:49 EST
Message-Id: <8901031854.AA13187@mist.>
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue COMPILER-DIAGNOSTICS, v7
Date: Tue, 03 Jan 89 13:54:47 EST
From: Dan L. Pierson <pierson@mist.encore.com>
[[Meta-note to cl-cleanup. One of the proposals for handling compiler
messages is based on signalling all messages as conditions with the
standard signalling function "printing" the message iff the
condition isn't handled. I think that this approach can, and
should, be applied to messages in the cleanup domain as well so I'm
forwarding just this message to cleanup to get a sense of the
sentiment there.]]
Part of my objection is that the name NOTICE is too vanilla.
There are other possible meanings and I can see people being bummed
if we use it up.
The Lisp Machine has a thing called a notification. I might be
susceptible to calling the type a NOTIFICATION and making a function
called NOTIFY. Then, at least, there would be current practice behind
the idea.
I have no objection to these name changes.
In another message, you suggested things like
Compiling FOO.
could be controlled by this, but there's already a competing proposal
for a :PRINT keyword to COMPILE-FILE which would cause that kind of
thing to go to STANDARD-OUTPUT (presumably unconditionally). I don't
want -too- many ways to do the same thing, so we should be careful about
our motivation.
That's true. I am mildly opposed to the competing proposal because
it's redundant with mine. I am strongly in favor of one general
condition-based mechanism for all of these messages.
If we made a notification facility, I think it should be done by Cleanup,
not compiler. Then perhaps GC messages could be done using it, and
the GC-MESSAGES issue (which deals with suppressing such messages) could
be handled as part of the same thing, too.
No object, since it also came up in connection with Moon's comments on
GC-MESSAGES, if forwarding this to cl-cleanup as well.
I don't have time to pursue this further and I can't say for sure that
if someone fleshed this out that I would necessarily support it ... but
I am not unalterably opposed to it if it's done in a way that motivates
its use (and doesn't just go in randomly with not even an initial purpose),
doesn't lock down too many short highly generic names, etc.
I can try to come up with something, if a condition-based approach to
this whole problem looks acceptable.
∂03-Jan-89 1056 CL-Cleanup-mailer Re: Issue GC-MESSAGES (Version 2)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 10:56:16 PST
Received: from [73.0.0.15] by multimax.encore.com (5.59/25-eef)
id AA25865; Tue, 3 Jan 89 13:54:43 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA13178; Tue, 3 Jan 89 13:53:43 EST
Message-Id: <8901031853.AA13178@mist.>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue GC-MESSAGES (Version 2)
In-Reply-To: Your message of Tue, 03 Jan 89 12:50:00 -0500.
Date: Tue, 03 Jan 89 13:53:40 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Tue, 3 Jan 89 12:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 03 Jan 89 12:38:44 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I still think that focussing on GC messages is wrong, and
instead there should be a form that disables unsolicited
typeout in general, regardless of its source. Of course in
some operating systems it might be impossible to disable some
forms of unsolicited typeout, and in other operating systems
unsolicited typeout might not exist (that is, asynchronous
messages might always come out in a separate window). Thus
this facility would just do the best effort appropriate for
the particular implementation.
I agree in general. I further think that the cleanest way to handle
the problem is by having all such output be signalled.
This can't work for asynchronous, unsolicited typeout.
Maybe I did tack this on to the wrong message. GC-MESSAGES may well
have to be a special case, both because they're almost the only truly
asyncronous events that don't invoke a debugger, and because they have
special consing problems as Kent reminded us. I think that all (or
almost all) other messages can still be treated in one uniform way.
In a multiprocess
system, the cause of the condition leading to message output may not be
in a "user" process, so signalling in the originating process won't give
the user any control.
Well, the condition system spec doesn't talk about how handlers are or
aren't inherited across processes. Since handlers are dynamically
scoped, it might be assumed that a process "inherits" all the handers
in existence when it is created. While this is probably not true in
most (if not all) existing Lisp multiprocessing systems, it's absence
does make it much harder to bullet proof a delivered application.
In addition, if handlers are inherited, it would be nice for any lisp
system to allow a user to define handlers that will be inherited by
all processes; I realize that this may not be possible for system
processes in a Lisp Machine.
Also there may be multiple "user" processes and it
may not be obvious which one should receive the signal. I shouldn't
have to tell this to someone from Encore, you must have faced all these
issues already!
We have, but not in a Lisp context! In general you can either have a
special signal handling process or let each process do it's best. It
depends on what the signal and application are trying to do. A single
signal handing process doesn't scale well, so I wouldn't want to use
it for something like divide by zero execptions (if my code was
prepared to handle those efficiently and I could get them delivered to
the originating process(or)), but that probably doesn't matter for
user interfaces. On the other hand, scaling doesn't really matter
unless you have several multiple processors. A Mach approach is to
have one thread with receive rights to a port that gets all errors.
While I'm very concerned about language changes that might make a
parallel lisp harder to create or define, I've been less worried about
user interface issues like this. All of your hard objections apply
just as much to any error handling (or even invoking the debugger) as
they do to printing a message. We've adopted a condition system that
doesn't deal with any of these issues because the language standard
doesn't deal with multitasking (e.g. stack groups) at all, let alone
true parallel processing. If the condition system is going to be
useful to users (and customers), multitasking implementations are
going to have to find answers to many of these problems. It won't be
easy, but that does that mean that we'd be better off without a
condition system?
Also a special form that disables unsolicited typeout
during the dynamic extent of its body could interact with the operating
system to disable or defer operating-system-generated typeout, but in
most operating systems it would be much more difficult to arrange for
the operating system to signal a Lisp condition when it wants to type
something out.
True, but the stock hardware operating systems I've worked with don't
tend to type things out. They just signal errors, return a bad status
code, or abort your program. Of course, linked-in foreign language
code may do such a thing, but that's only a problem for
implementations that use such code themselves. Any typeout proposal
that we come up with isn't going to control what the user can do to
himself.
It's too bad it can't work, because it certainly would be cleaner.
It can't work for GC-MESSAGES, but does that mean it can't work for
the loader, compiler, etc? I'm not convinced yet.
∂03-Jan-89 1227 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Jan 89 12:27:03 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514582; Tue 3-Jan-89 15:25:04 EST
Date: Tue, 3 Jan 89 15:24 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890103-113603-1600@Xerox>
Message-ID: <890103152425.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 3 Jan 89 11:35 PST
From: masinter.pa@Xerox.COM
Well, I think it is enforcable, if you have specialized storage.
Can you give me a concrete example? I'm basically saying that since it's you
that wants to introduce a restriction, the burden of proof is on you to show
a single example where the restriction buys you somthing. If you think it
does buy you something, I'm not calling you a liar -- I'm just saying I'm not
able to see the example you're hinting at.
So far, the only concrete example we have is one which has a perfectly
legitimate interpretation or an "is an error" interpretation. You're saying
you want to opt for the "is an error" interpretation, but you're not saying
what I buy for giving up the flexibility.
As soon as we start talking about concrete examples, I think we'll be making
headway.
∂03-Jan-89 1507 CL-Cleanup-mailer ballot
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 15:07:20 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA01829; Tue, 3 Jan 89 16:06:06 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06115; Tue, 3 Jan 89 16:06:00 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032306.AA06115@defun.utah.edu>
Date: Tue, 3 Jan 89 16:05:56 MST
Subject: ballot
To: cl-cleanup@sail.stanford.edu
Here's my ballot. I represent (officially) the University of Utah CS
department.
ARGUMENTS-UNDERSPECIFIED:SPECIFY Y
Version 4, 21-Sep-88, Mailed 4 Dec 88
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING Y
Version 9, 31-Oct-88, Mailed 5 Dec 88
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY Y
Version 5, 5-Dec-88, Mailed 5 Dec 88
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE Y
Version 1, 14-Sep-88, Mailed 6 Oct 88
DECLARATION-SCOPE:NO-HOISTING Y
DECLARATION-SCOPE:LIMITED-HOISTING N
Version 4, 15-Nov-88, Mailed 9-Dec-88
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION Y
Version 4, 5-Dec-88, Mailed 5-Dec-88
DECLARE-TYPE-FREE:ALLOW Y
Version 8, 7-Dec-88, Mailed 9-Dec-88
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE A
Version 2, 30-Sep-88, Mailed 6 Oct 88
DEFPACKAGE:ADDITION Y
Version 7, 2-Nov-88, Mailed 5 Dec 88
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY Y
Version 2, 21-Sep-88, Mailed 6 Oct 88
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES Y
Version 3, 7 Dec 88, Mailed 12-Dec-88
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR Y
Version 4, 31-Oct-88, Mailed 12-Dec-88
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE N
DESCRIBE-INTERACTIVE:NO Y
Version 4, 15-Nov-88 , Mailed 7-Dec-88
DOTTED-MACRO-FORMS:ALLOW Y
Version 3, 15-Nov-88, Mailed 7-Dec-88
EQUAL-STRUCTURE:STATUS-QUO A
Version 5, 1-Oct-88, Mailed 8 Oct 88
EXIT-EXTENT:MINIMAL N
EXIT-EXTENT:MEDIUM Y
Version 5, 12-Dec-88, Mailed 12-Dec-88
EXPT-RATIO:P.211 Y
Version 3, 31-Oct-88, Mailed 7 Dec 88
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION I*
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM Y
Version 4, 7-Dec-88, Mailed 12-Dec-88
* I will vote for TIGHTEN-DEFINITION if TIGHTEN-FIXNUM-TOSS-BIGNUM
is voted down.
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN A
Version 2, 2 Oct 88, Mailed 6 Oct 88
FORMAT-PRETTY-PRINT:YES Y
Version 7, 15 Dec 88, Mailed 7 Dec 88
FUNCTION-COMPOSITION:NEW-FUNCTIONS N
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS Y
Version 4, 12 Dec 88, Mailed 12 Dec 88
FUNCTION-DEFINITION:FUNCTION-SOURCE Y
Version 2, 09-Dec-88 , Mailed 9 Dec 88
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE Y
Version 3, 7-Dec-88, Mailed 12-Dec-88
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE A
Version 5, 14-Nov-88 , Mailed 8-Dec-88
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD Y
Version 2, 8 Dec 88, Mailed 8 Dec 88
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER N
Version 7, 8-Dec-88, Mailed 9-Dec-88
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS C*
Version 1, 11-Nov-88 , Mailed 12 Dec 88
* I agree with the sentiments expressed in the "additional comment"
at the end. I'd rather see a shorter proposal that deals only
with destructive operations on keys.
HASH-TABLE-TESTS:ADD-EQUALP N
Version 2, 8-Dec-88, Mailed 8 Dec 88
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY N
Version 4, 12-Dec-88, Mailed 12-Dec-88
LAMBDA-FORM:NEW-MACRO N
Version 4, 22-Nov-88, Mailed 8-Dec-88
LCM-NO-ARGUMENTS:1 Y
Version 1, 17 Oct 88, Mailed 8 Dec 88
LISP-SYMBOL-REDEFINITION:DISALLOW Y
Version 5, 22-Nov-88, Mailed 8 Dec 88
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT N
Version 2, 8 Oct 88, Mailed 12-Dec-88
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE Y
Version 2, 09-Jun-88, Mailed 8 Oct 88
NTH-VALUE:ADD N
Version 4, 8-Dec-88, Mailed 8 Dec 88
PACKAGE-CLUTTER:REDUCE I*
Version 6, 12-Dec-88, Mailed 12-Dec-881
* I don't see any need to restrict the use of internal symbols in
the LISP package as property indicators. Otherwise I support the
proposal.
PACKAGE-DELETION:NEW-FUNCTION A
Version 5, 21 nov 88, Mailed 8 Dec 88
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN I*
Version 1 27-Jun-88, Mailed 7 Oct 88
* :UNSPECIFIC should be legal in all pathname fields, not just in the
type field.
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR N, C*
Version 3, 8-Oct-88, Mailed 8 Oct 88
* This proposal seems to be in conflict with the rationale for
issue UNREAD-CHAR-AFTER-PEEK-CHAR, which is to legitimize
implementing PEEK-CHAR as READ-CHAR/UNREAD-CHAR.
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK I*
Version 3, 20 Sep 88, Mailed 8 Oct 88
* This proposal would be OK if it specified that circularity only
had to be detected for objects that are contained in slots of the
structure, not random objects that are printed out by the structure
print function. Rationale: an obvious way to handle circular
printing is to traverse the structure to detect circularities before
printing anything.
PROCLAIM-LEXICAL:LG N*
Version 9, 8-Dec-88, Mailed 12-Dec-88
* I don't have any fundamental complaint with this issue, but I believe
we need more experience with this feature before it should be
standardized.
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER Y
Version 3, 9-Oct-88, Mailed 14-Oct-88
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL Y
Version 1, 14-Sep-88, Mailed 7 Oct 88
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE Y
Version 6, 9 Dec 88, mailed 09 Dec 88
REST-LIST-ALLOCATION:NEWLY-ALLOCATED N
REST-LIST-ALLOCATION:MAY-SHARE Y
REST-LIST-ALLOCATION:MUST-SHARE N
Version 3, 12-Dec-88, mailed 12-Dec-88
RETURN-VALUES-UNSPECIFIED:SPECIFY Y
Version 6, 9 Dec 88 mailed 9-Dec-88
ROOM-DEFAULT-ARGUMENT:NEW-VALUE A
Version 1 12-Sep-88 mailed 8 Oct 88
[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS N
Version 3, 4-Nov-87, mailed Nov 87
SETF-PLACES:ADD-SETF-FUNCTIONS I*
Version 1, 11-Nov-88, mailed 9-Dec-88
* I already commented separately on this issue.
SETF-SUB-METHODS:DELAYED-ACCESS-STORES Y
Version 5, 12-Feb-88 mailed 8 Oct 88
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS Y
Version 8, 8 Jul 88, Mailed 7 Oct 88
STEP-ENVIRONMENT:CURRENT Y
Version 3, 20-Jun-88, mailed 7 Oct 88
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS I*
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
* If the amendment is accepted.
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS Y
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
SUBTYPEP-TOO-VAGUE:CLARIFY Y
Version 4, 7-Oct-88, mailed 7 Oct 88
SYMBOL-MACROLET-DECLARE:ALLOW I*
Version 2, 9-Dec-88, mailed 9 Dec 88
* Only if SYMBOL-MACROLET-SEMANTICS passes.
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM A
Version 5, 30-Nov-88, mailed 9 Dec 88
TAGBODY-CONTENTS:FORBID-EXTENSION Y
Version 5, 9-Dec-88 mailed 9 Dec 88
TAILP-NIL:T Y
Version 5, 9-Dec-88, mailed 12-Dec-88
TEST-NOT-IF-NOT:FLUSH-ALL Y
TEST-NOT-IF-NOT:FLUSH-TEST-NOT I*
Version 3, 1 Dec 88 mailed 9 dec
* Flushing some is better than not flushing all.
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS Y
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW Y
Version 2, 2-Dec-88, mailed 12-Dec-88
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE Y
Version 3, 08-Oct-88, mailed 9 Dec 88
-------
∂03-Jan-89 1818 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89 18:18:13 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 JAN 89 11:36:03 PST
Date: 3 Jan 89 11:35 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 3 Jan 89 01:31 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <890103-113603-160@Xerox>
Well, I think it is enforcable, if you have specialized storage.
I think the direction of your inference is backward. ALLOW is more powerful
than LEXICAL. A program that is correct using ALLOW semantics remains
correct using LEXICAL semantics. Thus, an implementation that can only
enforce LEXICAL will still accept programs that are correct under ALLOW.
The converse is not true.
Thus, ALLOW is more restrictive, and it allows implementations more
freedom, while not putting any unreasonable constraints on programs that
want to use declarations.
∂03-Jan-89 1819 CL-Cleanup-mailer meeting in Hawaii
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89 18:19:29 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 JAN 89 13:20:07 PST
Date: 3 Jan 89 13:09 PST
From: masinter.pa@Xerox.COM
Subject: meeting in Hawaii
To: cl-cleanup@sail.stanford.edu
Message-ID: <890103-132007-189@Xerox>
How many of you would be available for a meeting on Sunday? Thursday?
∂03-Jan-89 1820 CL-Cleanup-mailer Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89 18:20:05 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 03 JAN 89 18:17:29 PST
Date: 3 Jan 89 17:03 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 22 Dec 88 18:44 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890103-181729-1162@Xerox>
I like INTERCHANGABLE too.
I thought we might actually do more to backquote than just this.
∂03-Jan-89 2230 CL-Cleanup-mailer Issue: REST-LIST-ALLOCATION (Version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 22:30:35 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03970g; Tue, 3 Jan 89 22:25:13 PST
Received: by bhopal id AA01102g; Tue, 3 Jan 89 22:27:25 PST
Date: Tue, 3 Jan 89 22:27:25 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901040627.AA01102@bhopal>
To: will@fog.cs.uoregon.edu
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: William Clinger's message of Tue, 3 Jan 89 08:59:44 PDT <8901031659.AA06887@fog.cs.uoregon.edu>
Subject: Issue: REST-LIST-ALLOCATION (Version 3)
re: To my way of thinking, APPLY never copies any arguments so APPLY is
perfectly consistent with FUNCALL even if &REST lists are always
freshly consed. You see, my understanding of APPLY is that it calls
its first argument on the elements of the list that is its second
argument (or the analagous thing if you give it more than two arguments).
The arguments, therefore, are the elements of the list, not the list
itself, and so the arguments are not copied.
There was much debate on the Common-Lisp mailing list some months back,
and I vaguely remember the upshot being that "users" definitely did not
want the _default_ state of &rests to be anything optimized -- it leads
to far too much confusion when debugging. On the other side, numerous
implementors (especially those with roots in MIT) argued at length for
the freedom to make one or other time-saving or space-sharing hack.
In acknowledgement of the trade-off between efficiency and "clean,
simple" semantics, people seemed willing to allow a declaration which
permited one or more of these hacks. For example, DYNAMIC-EXTENT could
be applied to the variable holding the &rest argument, meaning that
it is OK to stack-cons it. Gail Zacharias stated this position most
succinctly -- the demand for simple semantics by default, with "hair"
to be added at the users discretion -- although it would take me a
while to resurrect the old mail. [Frankly, however, I don't remember
anyone proposing a declaration/proclamation that permitted the
APPLY-->&rest hack.]
Many of the arguments against "sharing" were similar to what I've quoted
from your msg above. I agree with your explanation of APPLY, even
though I'm an implementor with "roots in MIT" (actually, so is GZ!).
Lucid's implementation works similar to Xerox/Envos' Medley in regard
to &rest treatment; however it does have a stack-consing capability
enabled by declarations. Either way, as Larry Masinter points out,
it would be a tremendous re-vamp of the implemntation to even permit
the smallest amount of sharing when called via APPLY.
-- JonL --
∂04-Jan-89 0103 CL-Cleanup-mailer Issue: HASH-TABLE-STABILITY (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 01:03:11 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04034g; Wed, 4 Jan 89 00:59:24 PST
Received: by bhopal id AA01426g; Wed, 4 Jan 89 01:01:36 PST
Date: Wed, 4 Jan 89 01:01:36 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901040901.AA01426@bhopal>
To: IIM@ECLA.USC.EDU
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kim A. Barrett's message of 2 Jan 89 15:20 PST <890102-152101-1732@Xerox>
Subject: Issue: HASH-TABLE-STABILITY (Version 1)
re: (if (numberp x) (sxhash x) (%unique-no x))
the NUMBERP test really should be (OR (NUMBERP X) (CHARACTERP X)), ...
Ooops, right. Thanks for noticing it.
I've also noticed a bit of inconsistency in the use of the term
"key transformation". The "terminology" section mentions two
variant meanings for the term, but I'd prefer now to see it made
more rigorous; perhaps "hash function" could be used for the
variant which is typically dependent on the table size.
-- JonL --
∂04-Jan-89 0140 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 01:40:51 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04040g; Wed, 4 Jan 89 01:37:07 PST
Received: by bhopal id AA01494g; Wed, 4 Jan 89 01:39:19 PST
Date: Wed, 4 Jan 89 01:39:19 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901040939.AA01494@bhopal>
To: masinter.pa@Xerox.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 2 Jan 89 22:12 PST <890102-221315-1967@Xerox>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
re: If I say (DECLARE (TYPE (SIGNED-BYTE 12) X)), I'd think I'd like it to mean
that X never even momentarily holds a value that isn't of the declared
type.
For "bound" type declarations, it does mean this -- because the lexical
scope includes all the code that can ever be executed during the dynamic
extent of that (binding) contour. But for "free" type declarations,
we have a choice; we can say that it applies to the lexical scope,
or that it applies to the dynamic extent. Clearly, the former is
simpler, and more in line with our other views on declaration
scoping; see for example this issue DECLARATION-SCOPE, especially
the parallelism between the scoping rules for variables (lexical)
and those for declarations.
re: I'd like to see the writeup make it clear that the following is subsumed;
note that this issue never was released or appeared on a Status list, so
it should probably just be included:
Date: Fri, 4 Nov 88 18:05:21 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SPECIAL-TYPE-SHADOWING (V1)
. . .
Proposal SPECIAL-TYPE-SHADOWING:CLARIFY
Clarify that if there is a local type declaration for a special
variable, and there is also a global type proclamation for that same
variable, then the value of the variable within the scope of the local
declaration must be a member of the intersection of the two declared
types.
I don't think it is subsumed. The various versions of DECLARE-TYPE-FREE
permitted an inner nested declaration to be merely overlapping with
an outer declaration; but Gray's proposal requires local (read: "inner")
declarations to be subtypes of the global proclamations (read: "outter")
-- JonL --
∂04-Jan-89 0206 CL-Cleanup-mailer Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 02:06:35 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04049g; Wed, 4 Jan 89 02:02:39 PST
Received: by bhopal id AA01559g; Wed, 4 Jan 89 02:04:51 PST
Date: Wed, 4 Jan 89 02:04:51 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901041004.AA01559@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: masinter.pa@Xerox.COM, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Kent M Pitman's message of Tue, 3 Jan 89 01:46 EST <890103014612.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
re: I have a problem with version 2 because I don't think anything requires
get-dispatch-macro-character to return the same function on successive
calls even with the same readtable (provided the functions returned are
equivalent). As such, the example is inappropriate where it uses ASSERT
and EQ.
There is no "Examples" section in this proposal -- perhaps you meant
"Test Case"? As such, it's clear that the test case can only be
applied to implementations where GET-MACRO-CHARACTER returns the same
thing between two successive calls which don't modify the table.
It would be hard to imagine writing a test case where you had to solve
the Turing Machine Halting problem first. Determining whether two
function objects (i.e. functions as returned by GET-MACRO-CHARACTER)
define the same mathematical function is equivalent to the Halting
problem.
-- JonL --
∂04-Jan-89 0210 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL ?
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 02:10:44 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04052g; Wed, 4 Jan 89 02:06:12 PST
Received: by bhopal id AA01565g; Wed, 4 Jan 89 02:08:19 PST
Date: Wed, 4 Jan 89 02:08:19 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901041008.AA01565@bhopal>
To: eb@lucid.com
Cc: masinter.pa@Xerox.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Eric Benson's message of Tue, 3 Jan 89 07:54:37 pst <8901031554.AA00248@blacksox>
Subject: Issue: PATHNAME-LOGICAL ?
re: Yes, I meant to say logical pathnames.
Or, did you say, PATH-LOGICAL NAMES?
-- JonL --
∂04-Jan-89 0224 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 02:24:33 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04062g; Wed, 4 Jan 89 02:20:45 PST
Received: by bhopal id AA01609g; Wed, 4 Jan 89 02:22:57 PST
Date: Wed, 4 Jan 89 02:22:57 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901041022.AA01609@bhopal>
To: pierson@mist.encore.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dan L. Pierson's message of Tue, 03 Jan 89 12:15:07 EST <8901031715.AA12970@mist.>
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
re: But if all that Dan wanted to say was that the array
references were assumed to satisfy the *upgrade* of the declared type,
then there would be no problem (with that part).
Sorry, but that's exactly the opposite of what I meant. If I declare
an array, FOO, to be (SIGNED-BYTE 5), within the scope of that
definition I'm saying that expect references to that array to be
equivalent to:
(THE (SIGNED-BYTE 5) (AREF FOO X))
No matter what the array was upgraded to.
Yea, that's what I thought you meant, and that's what I think is
inconsistent with the "unification" in issue ARRAY-ELEMENT-TYPE-SEMANTICS.
re: Actually, your name got put in support because of an early message of
yours (which I finally found) in the ARRAY-ELEMENT-TYPE-SEMANTICS
discussion. I'll be happy to remove your name if we now disagree.
I fear that my very first reading of DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
was too hasty, and I incorrectly thought it was subsumed by
ARRAY-ELEMENT-TYPE-SEMANTICS. I'm sure I recanted that apostasy in
later mail.
re: As I've said before, I support a strict type checking mode for all
Common Lisp compilers. However I now suspect that it's too late (and
maybe too experimental) to get in this version of the standard. I
said I'd write up a proposal for it at the cleanup meeting last
October, but was later talked out of doing so.
Why? [i.e., Why did you get "talked out of doing so"?] I remember
discussing this with you at length during the Palo Alto meeting in
March 1988 and likeing it very much. However -- I hasten to point
out -- it would help not to confuse this issue with the very limited
scope of DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES, which has it's own
peculiar problems related to "upgrading".
-- JonL --
∂04-Jan-89 0311 CL-Cleanup-mailer Re: Issue FIXNUM-NON-PORTABLE, v4
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 4 Jan 89 03:11:07 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03629; 4 Jan 89 10:47 GMT
Date: Tue, 3 Jan 89 17:26:31 GMT
Message-Id: <29459.8901031726@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue FIXNUM-NON-PORTABLE, v4
To: "Kim A. Barrett" <IIM@ecla.usc.edu>, cl-cleanup@sail.stanford.edu
In-Reply-To: Kim A. Barrett's message of Sat 31 Dec 88 19:47:14-PST
Cc: iim@ecla.usc.edu
> There are relatively few legitimate uses of FIXNUM in portable code,
While I sometimes use such arguments myself, I do not think it is
true in general that only portable code matters. I want fixnums
because they let me do something is the same way in all implementations
that do it. Also, in most implementations fixnums are big enough to
contain the address part of a pointer to a data object. Therefore,
they are always big enough to count objects.
∂04-Jan-89 0623 CL-Cleanup-mailer Re: Issue FIXNUM-NON-PORTABLE, v4
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 06:23:11 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA01227; Wed, 4 Jan 89 09:21:59 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA13950; Wed, 4 Jan 89 09:22:00 EST
Message-Id: <8901041422.AA13950@mist.>
To: Jeff Dalton <"jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK"@multimax.encore.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue FIXNUM-NON-PORTABLE, v4
In-Reply-To: Your message of Tue, 03 Jan 89 17:26:31 +0000.
<29459.8901031726@subnode.aiai.ed.ac.uk>
Date: Wed, 04 Jan 89 09:21:57 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Also, in most implementations fixnums are big enough to
contain the address part of a pointer to a data object. Therefore,
they are always big enough to count objects.
Note that this proposal does not guarantee that fixnums will be large
enough for your purposes; all Common Lisp systems will need more than
16 address bits...
∂04-Jan-89 1116 CL-Cleanup-mailer Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 11:15:55 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA02902; Wed, 4 Jan 89 13:53:40 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA14296; Wed, 4 Jan 89 13:53:41 EST
Message-Id: <8901041853.AA14296@mist.>
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
In-Reply-To: Your message of Wed, 04 Jan 89 02:22:57 -0800.
<8901041022.AA01609@bhopal>
Date: Wed, 04 Jan 89 13:53:39 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Sorry, but that's exactly the opposite of what I meant. If I declare
an array, FOO, to be (SIGNED-BYTE 5), within the scope of that
definition I'm saying that expect references to that array to be
equivalent to:
(THE (SIGNED-BYTE 5) (AREF FOO X))
No matter what the array was upgraded to.
Yea, that's what I thought you meant, and that's what I think is
inconsistent with the "unification" in issue ARRAY-ELEMENT-TYPE-SEMANTICS.
It seems that we disagree here. I'll remove your endorsement from the
next version of the proposal.
re: As I've said before, I support a strict type checking mode for all
Common Lisp compilers. However I now suspect that it's too late (and
maybe too experimental) to get in this version of the standard. I
said I'd write up a proposal for it at the cleanup meeting last
October, but was later talked out of doing so.
Why? [i.e., Why did you get "talked out of doing so"?] I remember
discussing this with you at length during the Palo Alto meeting in
March 1988 and likeing it very much. However -- I hasten to point
out -- it would help not to confuse this issue with the very limited
scope of DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES, which has it's own
peculiar problems related to "upgrading".
Well, it was a combination of factors: the issue looked to be
extremely controversial; several well respected people were arguing
against much milder proposals on the grounds that no one had
implemented them (FUNCTION-COMPOSITION comes to mind); and Larry made
a strong pitch that time was running out and we should concentrate our
efforts on the important issues that still might be resolved in time.
I clearly don't have time to do a full writeup by Hawaii, but am still
willing to consider doing one later; I've also considered a Lisp
Pointers article as an alternative or addition. It seems that a very
relevant question is whether any vendors would consider making such a
feature part of their product if it wasn't required. If the answer to
that is no, then I would have to reluctantly admit that the
standardization case is -very- weak.
Right now, I'm more likely to devote time to a foreign function
interface standard, since almost everyone implements the feature and
many of the differences are clearly unnecessary, if not plain
gratuitous. The same arguments might apply to multiprocessing ala
stack groups (though emphatically not to parallel lisp).
Just to remove any doubt, I personally think that such a "string
typing" feature is very, very valuable and have felt and argued that
way since the early VAX Lisp days. For one thing, the lack of this
feature makes it extremely difficult to move a non-trivial application
from low SPEED, high SAFETY to the reverse. You currently have to go
straight from generic operations that "always" work to no-holds-barred
inline code where errors can do anything; a mode that checked your
declarations and signalled precise errors would make debugging and QA
of such an application vastly easier. If we want people to produce
serious applications and products with Common Lisp, we have to give
them the tools to produce efficient and safe code without sacrificing
the traditional development advantages of Lisp. This feature helps do
exactly that.
∂04-Jan-89 1137 CL-Cleanup-mailer Re: Issue FIXNUM-NON-PORTABLE, v4
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 4 Jan 89 11:37:25 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06991; 4 Jan 89 19:11 GMT
Date: Wed, 4 Jan 89 19:16:04 GMT
Message-Id: <1732.8901041916@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue FIXNUM-NON-PORTABLE, v4
To: Jeff Dalton <"jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK"@multimax.encore.com>,
pierson <@multimax.encore.com:pierson@mist.encore.com>
Cc: cl-cleanup@sail.stanford.edu
> Also, in most implementations fixnums are big enough to
> contain the address part of a pointer to a data object. Therefore,
> they are always big enough to count objects.
>
> Note that this proposal does not guarantee that fixnums will be large
> enough for your purposes; all Common Lisp systems will need more than
> 16 address bits...
That's one of the problems with saying 16 bits: it might increase the
likelihood that implementations will do something that losing. It would
be nice if there were some way to test whether fixmuns were big enough
(if we can't actually guarantee it), but it's worth noting that right
now fixnums work better for this purpose that any particular number of
bits I might pick.
∂04-Jan-89 1503 CL-Cleanup-mailer Issue PATHNAME-PRINT-READ, v1
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89 15:02:57 PST
Date: Wed 4 Jan 89 13:57:23-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue PATHNAME-PRINT-READ, v1
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12459944142.14.IIM@ECLA.USC.EDU>
For Current Practice, IIM Common Lisp prints pathnames with the syntax
#.(parse-namestring "asdf" "host"). The reason for using this convention is
that for some strings you need to know what parsing conventions to use in order
to get back an equivalent pathname. And yes, I agree it is ugly and verbose.
kab
-------
∂04-Jan-89 1547 CL-Cleanup-mailer meeting in Hawaii
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Jan 89 15:46:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515446; Wed 4-Jan-89 18:45:15 EST
Date: Wed, 4 Jan 89 18:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: meeting in Hawaii
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890103-132007-189@Xerox>
Message-ID: <19890104234443.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 3 Jan 89 13:09 PST
From: masinter.pa@Xerox.COM
How many of you would be available for a meeting on Sunday? Thursday?
I will be there Sunday but not Thursday.
∂04-Jan-89 1549 CL-Cleanup-mailer Issue PATHNAME-PRINT-READ, v1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Jan 89 15:49:13 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515448; Wed 4-Jan-89 18:48:01 EST
Date: Wed, 4 Jan 89 18:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue PATHNAME-PRINT-READ, v1
To: IIM@ECLA.USC.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <12459944142.14.IIM@ECLA.USC.EDU>
Message-ID: <890104184739.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Yes, hosting is an issue that I deliberately glossed in the proposal.
Let me say a few words about that and other issues that have been raised.
- I think #P is better than #. for the same reasons that Touretzky
proposed #H instead of relying on #. . That is, because most Lisp
data can be understood by engines considerably less complex than
Lisp itself. Lists, numbers, etc. are parseable and manipulable
[are those really words? I say them a lot but they look funny
written down..] by simpler programs which do not contain EVAL.
Using #. makes a large barrier to such programs in manipulating
any data involving pathnames, which a priori should not be an
opaque concept to non-Lisp programs.
- The issue of hosts is more severe in a multi-file-system
environment than many CL implementors working in single-file-system
environments may realize. At Symbolics, the decision was made a
long time ago to use what's called the `host colon' convention.
Basically, it says that the first `:' in a filename is -always-
the separator of the host from other host-specific syntax. To
avoid ambiguity, we simply define that you cannot have a
namestring with a device specifier (or whatever other host-specific
thing a `:' may mean) without having a host specifier. So, if my
default host is a Tops-20 named Hydrogen, I can write "<FOO>" or
"H:<FOO>" to mean "<FOO>" on Hydrogen, but if there is a device
"H" on Hydrogen, I must write either "H:H:<FOO>"
(to be context-independent) or ":H:<FOO>" (if I know that H is
the default and I want to get past the `host colon'. Our
NAMESTRING and PARSE-NAMESTRING obey these same conventions.
So Symbolics pathnames print as #P"host:asdf" (to use your example
above) without ambiguity. But I agree that without such a convention,
there are still some rough edges. To make things work for external
interfaces, though, pathnames support a :string-for-host message
which gives you the string the file system wants to see.
I have not proposed the Symbolics solution (which was a major
changeover at the time it was introduced) even though I think it's
the right thing (and has solved a lot of major problems) mostly
because I've seen serious resistance [eg, in issue PATHNAME-COMPONENT-CASE]
to solving issues of multiple file systems. My impression is that
enough people either believe that there is only one file system in
the world or only one that they'll ever have to deal with or
or at least only one that they'll have to deal with in any given
running Lisp that they feel comfortable just sweeping these issues
under the rug. I think that's very sad, and I think they're making
a big mistake, but there's only so much I can do. Either someone
else with multiple-file-system experience needs to stand up and
help with this problem, or someone from the single-file-system
world needs to our community a vote of confidence that we're not
pushing these things on people gratuitously, or else people should
just hang it up and expect to get screwed by cross-host problems
such as the very real one you allude to.
∂04-Jan-89 1633 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, v1
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89 16:32:59 PST
Date: Wed 4 Jan 89 13:59:03-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, v1
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12459944447.14.IIM@ECLA.USC.EDU>
> Date: Tue, 3 Jan 89 08:10:38 pst
> From: Eric Benson <eb@lucid.com>
>
> MACRO-FUNCTION should not accept the environment argument received by
> an *EVALHOOK* or *APPLYHOOK* function. (*APPLYHOOK* should not even
> receive an environment argument, was there ever a cleanup issue
> addressing this?)
I want MACRO-FUNCTION to accept these so that MACROEXPAND (which does) can
simply pass such objects along to MACRO-FUNCTION. My expectation is that
MACRO-FUNCTION (or the underlying mechanism it is based on) will look at this
thing and say "nope, not a compiler environment, lets go look in the current
function cell (or wherever the implementation puts macro expander functions)".
Yes, if APPLYHOOK has been "cleaned up" then references to it should be removed
from this proposal.
> In that case, what does MACRO-FUNCTION return when there is a MACROLET
> definition visible? It must return some non-NIL value. It should be
> the expansion function, to be consistent with the global case.
Right, it should be an expander function. I don't have any really strong
preference for whether it actually "looks inside" the environment object to see
if there are any local definitions (macro or function). I mostly proposed it
work that way so that it stayed compatible with CLtL's description, which only
talks about global definitions. Of course, CLtL doesn't have it taking an
environment argument, so maybe I goofed here. However, as I mentioned in the
discussion, MACRO-FUNCTION is primarily used as a predicate and a place for
SETF. Does anybody outside of MACROEXPAND actually use the returned expander
function?
kab
-------
∂04-Jan-89 1641 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, v1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 16:41:25 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA04915g; Wed, 4 Jan 89 16:37:33 PST
Received: by blacksox id AA00536g; Wed, 4 Jan 89 16:39:53 pst
Date: Wed, 4 Jan 89 16:39:53 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901050039.AA00536@blacksox>
To: IIM@ECLA.USC.EDU
Cc: cl-cleanup@SAIL.STANFORD.EDU, iim@ECLA.USC.EDU
In-Reply-To: Kim A. Barrett's message of Wed 4 Jan 89 13:59:03-PST <12459944447.14.IIM@ECLA.USC.EDU>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, v1
I don't think MACROEXPAND should be required to accept EVALHOOK-type
environments either.
∂04-Jan-89 1900 CL-Cleanup-mailer meeting in Hawaii
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 19:00:32 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA05101g; Wed, 4 Jan 89 18:56:44 PST
Received: by bhopal id AA03464g; Wed, 4 Jan 89 18:58:56 PST
Date: Wed, 4 Jan 89 18:58:56 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901050258.AA03464@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 3 Jan 89 13:09 PST <890103-132007-189@Xerox>
Subject: meeting in Hawaii
I'll be available after about 4PM Sunday, and up until about 10AM Thursday.
-- JonL --
∂05-Jan-89 1113 CL-Cleanup-mailer Symbolics response to mail ballot
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Jan 89 11:12:39 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515914; Thu 5-Jan-89 14:11:27 EST
Date: Thu, 5 Jan 89 14:10 EST
From: Moon@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Symbolics response to mail ballot
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890105141057.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
These votes represent the official position of Symbolics.
Because of the volatility of some issues from version to version,
readers are reminded that our votes apply only to the indicated
versions of the writeup.
In the notes column, "comment" means we have comments which do
not necessarily affect our vote, but which we felt important
to mention. On the other hand, "provisional" means that
we have placed conditions on the indicated vote, and the vote does
not apply unless the conditions are met. Comments and provisions
follow at the end of this message.
Blank lines in the summary are just for readability. They don't
indicate any kind of grouping.
---Summary---
Issue:Proposal(Version) Vote Notes
ARGUMENTS-UNDERSPECIFIED:SPECIFY(4) Yes ---
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING(9) Yes comment
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY(5) Yes ---
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE(1) Yes ---
DECLARATION-SCOPE:LIMITED-HOISTING(4) Yes ---
DECLARATION-SCOPE:NO-HOISTING(4) No ---
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION (4) Yes comment
DECLARE-TYPE-FREE:ALLOW(8) No comment
DECLARE-TYPE-FREE:LEXICAL(9, unreleased) Yes comment
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE(2) Yes ---
DEFPACKAGE:ADDITION(7) Yes comment
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY(2) Yes comment
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES(3) Yes ---
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR(4) Yes ---
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE(4) Yes ---
DESCRIBE-INTERACTIVE:NO(4) No comment
DOTTED-MACRO-FORMS:ALLOW(3) Yes ---
EQUAL-STRUCTURE:STATUS-QUO(5) No comment
EXIT-EXTENT:MINIMAL(5) No comment
EXIT-EXTENT:MEDIUM(5) No comment
EXPT-RATIO:P.211(3) Yes ---
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION(4) Yes ---
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM(4) No ---
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN(2) Yes ---
FORMAT-PRETTY-PRINT:YES(7) Yes comment
FUNCTION-COMPOSITION:NEW-FUNCTIONS(4) Yes comment
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS(4) No comment
FUNCTION-DEFINITION:FUNCTION-SOURCE(2) Yes ---
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE(3) Yes ---
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE(5) Yes comment
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD(2) Yes comment
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER(7) Yes comment
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS(1) No comment
HASH-TABLE-TESTS:ADD-EQUALP(2) Yes comment
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY(4) Yes provisional
LAMBDA-FORM:NEW-MACRO(4) Yes ---
LCM-NO-ARGUMENTS:1(1) Yes ---
LISP-SYMBOL-REDEFINITION:DISALLOW(5) Yes provisional
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT(2) No comment
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE(2) Yes ---
NTH-VALUE:ADD(4) Yes comment
PACKAGE-CLUTTER:REDUCE(6) Yes comment
PACKAGE-DELETION:NEW-FUNCTION(5) Yes ---
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN(1) Yes ---
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR(3) Yes comment
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK(3) Yes ---
PROCLAIM-LEXICAL:LG(9) Yes comment
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER(3) Yes ---
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL(1) Yes ---
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE(6) Yes ---
REST-LIST-ALLOCATION:MAY-SHARE(3) Yes ---
REST-LIST-ALLOCATION:NEWLY-ALLOCATED(3) No ---
REST-LIST-ALLOCATION:MUST-SHARE(3) No ---
RETURN-VALUES-UNSPECIFIED:SPECIFY(6) Yes ---
ROOM-DEFAULT-ARGUMENT:NEW-VALUE(1) Yes ---
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS(3) No comment
SETF-PLACES:ADD-SETF-FUNCTIONS(1) No comment
SETF-SUB-METHODS:DELAYED-ACCESS-STORES(5) Yes ---
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS(8) Yes ---
STEP-ENVIRONMENT:CURRENT(3) Yes provisional
STREAM-ACCESS:ADD-TYPES-ACCESSORS(2) Yes comment
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS(2) No comment
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS(2) No comment
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS Yes provisional
SUBTYPEP-TOO-VAGUE:CLARIFY(4) Yes comment
SYMBOL-MACROLET-DECLARE:ALLOW(2) Yes ---
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM(5) Yes ---
TAGBODY-CONTENTS:FORBID-EXTENSION(5) Yes provisional
TAILP-NIL:T(5) Yes comment
TEST-NOT-IF-NOT:FLUSH-ALL(3) Yes provisional
TEST-NOT-IF-NOT:FLUSH-TEST-NOT(3) Yes provisional
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS(3) Yes provisional
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW(2) Yes ---
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE(3) Yes ---
---Detail---
Comment on ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9, 31-Oct-88)
We don't think the functions UPGRADED-ARRAY-ELEMENT-TYPE and
UPGRADED-COMPLEX-PART-TYPE are really necessary, but neither of us
cares enough to pursue that issue. Otherwise it looks ok.
Comment on DECLARE-FUNCTION-AMBIGUITY (Version 4, 05-Dec-88)
Moon is mildly opposed to this proposal, DELETE-FTYPE-ABBREVIATION,
because he sees it as gratuitously incompatible. Pitman favors the
proposal because he thinks the benefit of making things regular will
outweigh the costs.
Comment on DECLARE-TYPE-FREE (Version 8, 07-Dec-88)
Moon approved of an earlier version of this proposal, and wrote
a new option, LEXICAL, as part of a version 9 which has not been
released to X3J13. Both Moon and Pitman support the LEXICAL proposal,
version 9.
Comment on DEFPACKAGE (Version 7, 02-Nov-88)
The semantics should be defined in terms of the existing package
functions rather than being redundantly described, in order to minimize
the risk that DEFPACKAGE and the package functions will accidentally
differ in some unintended way.
Comment on DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2, 21-Sep-88)
The proposal should accomodate comments by IIM about some keywords
that were (presumably accidentally) not addressed
Comment on DESCRIBE-INTERACTIVE (Version 4, 15-Nov-88)
We prefer option EXPLICITLY-VAGUE.
We would vote "Yes" for the NO option iff EXPLICITLY-VAGUE fails.
Comment on EQUAL-STRUCTURE (Version 5, 01-Oct-88)
There are important technical comments about EQUALP which have not
been addressed, and which we feel must be addressed before this is
brought to a serious vote. Ultimately, when those pending technical
comments have been addressed, we expect to buy into this proposal.
Comment on EXIT-EXTENT (Version 5, 12-Dec-88)
Sadly, we feel it is still premature to vote on this issue at this time.
There are too many errors and inconsistencies in the writeup.
Comment on FORMAT-PRETTY-PRINT (Version 7, 15-Dec-88)
Although some fixes were made to accomodate ~R, some minor lingering
questions remain, which should be addressed under separate cover:
- Is PRINT-OBJECT used to print things of type FLOAT in any cases
where ~$, ~E, ~F, or ~G is used?
- Can users write any methods (including :AROUND, :BEFORE, etc) for
PRINT-OBJECT on type FLOAT?
If the answers to both of these questions end up being "Yes", then it
matters whether any of those format ops bind *PRINT-BASE* in order to
achieve the effect prescribed by CLtL of always printing floats in
base 10. If the answer to either of those questions is "No", then
it doesn't matter.
Comment on FUNCTION-COMPOSITION (Version 4, 12-Dec-88)
Barry Margolin's complaint about the degenerate case of COMPOSE should be
fixed in both proposals.
We prefer option NEW-FUNCTIONS.
We would vote "Yes" for COMPLEMENT-AND-ALWAYS iff NEW-FUNCTIONS fails.
Comment on FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5, 14-Nov-88)
It turns out the list type specifier being contemplated wouldn't have
helped the case of alternating keyword value pairs because `repetitions'
were not among the issues being addressed by those working on that topic.
Comment on GET-MACRO-CHARACTER-READTABLE (Version 2, 8-Dec-88)
The proposal is ok, but the test case is wrong and should definitely be
fixed before a vote is called. EQness of successive results from
GET-MACRO-CHARACTER when given the same arguments is not guaranteed
currently, and the new proposal does not suggest causing such a thing.
Comment on HASH-TABLE-PACKAGE-GENERATORS (Version 7, 08-Dec-88)
The test-package-iterator example has the values from the generator in
the wrong order. This should be fixed before the actual vote.
Comment on HASH-TABLE-STABILITY (Version 1, 11-Nov-88)
We believe that it is not appropriate to vote on this issue at this
time. Neither of us had the patience to figure out in enough detail
what it was saying to have any confidence in our opinions on the issue.
If there is really something important going on here, it should be
possible to say briefly and in plain English what the problem being
addressed is and what the nature of the solution is. If, after a brief,
intelligible, high level discussion of the issue, details must be
presented to back up the high level goals, that would be fine.
Comment on HASH-TABLE-TESTS (Version 2, 08-Dec-88)
We would really like to see = hash tables, too.
Provision on IN-PACKAGE-FUNCTIONALITY (Version 4, 12-Dec-88)
Our "Yes" vote is contingent on the DEFPACKAGE passing.
Provision on LISP-SYMBOL-REDEFINITION (Version 5, 22-Nov-88)
We're reluctant to include the paragraph about permitting (DEFVAR CAR ...).
Our vote is "Yes" only if the paragraph suggesting this is permissible
is removed.
Comment on MAKE-PACKAGE-USE-DEFAULT (Version 2, 08-Oct-88)
We oppose this issue because:
- It is not clearly in the best interest of programmers in a supposedly
portable language to give up the most convenient package creation
syntax to a non-portable purpose.
- The justifications given in the proposal are not strong enough to
support an incompatible change like this.
- This is a special-case hack that does not generalize. There is
no way to create a package based on the implementation-dependent
default -and- other packages.
- It would be just as easy for someone to say
:USE (PACKAGE-USE-LIST (FIND-PACKAGE "USER"))
At least this technique generalizes.
- The Rationale uses incorrect suppositions to arrive at a false
generalization. Cloe doesn't have the asymmetry referred to.
- The current practice is not correct.
No mention of what Cloe does is attempted.
- Even allowing the default to be controlled by a variable does
not help because it encourages programs to be developed depending
on defaults which are not part of those programs, and therefore
works against portability.
- The Discussion section does not correctly reflect discussion.
For example, Pitman has repeatedly voiced strong opposition.
The Discussion mentions neither the fact that he objected nor the
reasons for his objection.
Comment on NTH-VALUE (Version 4, 08-Dec-88)
The proposal should clarify the treatment of n when it is out of range.
Any non-negative integer index values should be permitted.
NIL should result if the index argument is too large.
Comment on PACKAGE-CLUTTER (Version 6, 12-Dec-88)
This leaves implementations freedom to hack any properties other than
those in the LISP, KEYWORD, and USER packages. In fact, though, the
user should probably also have rights over the system in packages he
creates.
This will be an incompatible change -- possibly a major one -- for
Genera, which uses properties named by keywords and by symbols in the
LISP package. However, we think the change is worthwhile.
In general, Genera tries not to distinguish "the system" from "the user".
Anything the system is permitted to do, the user is permitted to do.
As such, we feel a little odd about placing restrictions on the system
which are not likewise placed on the user. In fact, if the system can
cause problems in this way, the user can, too. This proposal is only
heuristic. We're voting "Yes" because it's probably a change for the
better. But we won't be surprised if ultimately it is not seen to be
the right way to achieve the high-level goal.
LEXICAL, TYPE, INLINE, NOTINLINE, and FTYPE proclamations should be
explicitly ruled out (just as SPECIAL is) except that TYPE is allowed
if it's a CL variable, and FTYPE, INLINE, and NOTINLINE are allowed
if it's a CL function.
The DECLARATION proclamation probably be explicitly allowed (because
we see no reason not to permit it).
Comment on PEEK-CHAR-READ-CHAR-ECHO (Version 3, 08-Oct-88)
There are some typos in this proposal that need to be corrected.
Also, IIM asked for a clarification which seemed reasonable to us.
Comment on PROCLAIM-LEXICAL (Version 9, 08-Dec-88)
The proposal might want to define the status of unproclaimed free variables.
Presumably, we should say that they are an error, and we should encourage
compilers to issue a warning.
Comment on SETF-FUNCTION-VS-MACRO (Version 3, 04-Nov-87)
We think it's premature to vote on this issue at this time.
We suggest that a better proposal, unifying this issue with SETF-PLACES,
should be produced either before or during the upcoming meeting.
Comment on SETF-PLACES (Version 1, 11-Nov-88)
We think it's premature to vote on this issue at this time.
We suggest that a better proposal, unifying this issue with
SETF-FUNCTION-VS-MACRO, should be produced either before or during
the upcoming meeting.
Provision on STEP-ENVIRONMENT (Version 3, 20-Jun-88)
We don't understand
"it is acceptable for an implementation to interactively step
through only those parts of the evaluation that are interpreted."
There are a variety of ways to clarify this that would satisfy us.
Still, this must be clarified so we can know for sure what we're voting
on and have some confidence that other implementors will interpret it
in the same way as we have before we can vote "Yes".
Comment on STREAM-ACCESS (Version 2, 30-Nov-88)
Although requiring types instead of predicates forces the implementation
of these streams as separate types, there is no obvious serious problem
which can result from that, and it leaves open the possibility of writing
methods on particular types -- if they are also classes -- are they? The
proposal should spell this out.
Having both the types and the predicates is unnecessary clutter.
Omitting the predicates makes for less overhead with no lost functionality.
Provision on STREAM-INFO (Version 6, 30-Nov-88)
We vote "Yes" only if the name-changing amendment mentioned in the mail passes.
Also, the writeup incorrectly states that Newline is not a standard character;
Perhaps someone has confused "standard" with "graphic".
Comment on SUBTYPEP-TOO-VAGUE (Version 4, 07-Oct-88)
Some minor worry about DECLARE-FUNCTION-AMBIGUITY here since the proposal
mentions the list form of the FUNCTION declaration.
This is a complicated issue and we have not had time to think it through
as fully as we might like to have. Still, insofar as we have studied it,
it looks ok.
Provision on TAGBODY-CONTENTS (Version 5, 09-Dec-88)
The term "data element" is too vague in paragraph 2 of the proposal.
Our "Yes" vote is contingent on correcting this.
Moon doesn't really like allowing ignored frobs other than expressions
and tags, but is willing to live with the current proposal.
There several typos which should be fixed.
Comment on TAILP-NIL (Version 5, 09-Dec-88)
The EQ -> EQL change at the last minute means this is not Genera current
practice, contrary to the current practice section.
Provision on TEST-NOT-IF-NOT (Version 2, 05-Oct-88)
We are mostly happy with either of these proposals, with slight
preference to FLUSH-ALL. However, our "Yes" vote is contingent on:
- changing "remove" to "deprecate", and coming up with a
suitable policy for deprecation which allows a comfortable
transition from current practice.
- either of the FUNCTION-COMPOSITION proposals passing.
Provision on TYPE-OF-UNDERCONSTRAINED (Version 3, 12-Dec-88)
Our "Yes" vote is contingent on the following issues being addressed:
- RANDOM-STATE should be added to the list of built-in types.
- (subtypep (type-of x) (class-of x)) => T T for all x, seems to have
been intended but is not actually said. It should be added.
- The implementation recommendation in the discussion about returning
only portable type specifiers should be discarded.
- Shouldn't this refer to classes with proper names rather than just
ones with names?
∂05-Jan-89 1113 CL-Cleanup-mailer Issue PATHNAME-PRINT-READ, v1
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Jan 89 11:13:45 PST
Received: from JACKIE-O.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 159294; Thu 5-Jan-89 14:02:55 EST
Date: Thu, 5 Jan 89 14:03 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue PATHNAME-PRINT-READ, v1
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890104184739.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890105190305.1.MLY@JACKIE-O.AI.MIT.EDU>
I still don't understand why this needs to be standardised upon,
particularly since Common Lisp pathnames in general are so
subfunctional. (Just what can portable programs do with the damn things
after they have successfully read them?)
Even if others do feel an urgent need to allow such portablability, I
don't understand why #S(PATHNAME ...) syntax isn't acceptable. (Perhaps
because Pitman hadn't `invented' it yet.)
One could go with #S(PATHNAME "host:namestring")
or #S(PATHNAME "host" "namestring"), which is perhaps the best choice,
or #S(PATHNAME :host "host" :directory '("foo" "bar") :name "baz")
or whatever.
Usurping #P makes it harder for users to find an unused reader macro
character.
∂05-Jan-89 1208 CL-Cleanup-mailer Issue PATHNAME-PRINT-READ, v1
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Jan 89 11:13:45 PST
Received: from JACKIE-O.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 159294; Thu 5-Jan-89 14:02:55 EST
Date: Thu, 5 Jan 89 14:03 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue PATHNAME-PRINT-READ, v1
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890104184739.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890105190305.1.MLY@JACKIE-O.AI.MIT.EDU>
I still don't understand why this needs to be standardised upon,
particularly since Common Lisp pathnames in general are so
subfunctional. (Just what can portable programs do with the damn things
after they have successfully read them?)
Even if others do feel an urgent need to allow such portablability, I
don't understand why #S(PATHNAME ...) syntax isn't acceptable. (Perhaps
because Pitman hadn't `invented' it yet.)
One could go with #S(PATHNAME "host:namestring")
or #S(PATHNAME "host" "namestring"), which is perhaps the best choice,
or #S(PATHNAME :host "host" :directory '("foo" "bar") :name "baz")
or whatever.
Usurping #P makes it harder for users to find an unused reader macro
character.
∂05-Jan-89 1208 CL-Cleanup-mailer Symbolics response to mail ballot
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Jan 89 11:12:39 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515914; Thu 5-Jan-89 14:11:27 EST
Date: Thu, 5 Jan 89 14:10 EST
From: Moon@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Symbolics response to mail ballot
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890105141057.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
These votes represent the official position of Symbolics.
Because of the volatility of some issues from version to version,
readers are reminded that our votes apply only to the indicated
versions of the writeup.
In the notes column, "comment" means we have comments which do
not necessarily affect our vote, but which we felt important
to mention. On the other hand, "provisional" means that
we have placed conditions on the indicated vote, and the vote does
not apply unless the conditions are met. Comments and provisions
follow at the end of this message.
Blank lines in the summary are just for readability. They don't
indicate any kind of grouping.
---Summary---
Issue:Proposal(Version) Vote Notes
ARGUMENTS-UNDERSPECIFIED:SPECIFY(4) Yes ---
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING(9) Yes comment
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY(5) Yes ---
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE(1) Yes ---
DECLARATION-SCOPE:LIMITED-HOISTING(4) Yes ---
DECLARATION-SCOPE:NO-HOISTING(4) No ---
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION (4) Yes comment
DECLARE-TYPE-FREE:ALLOW(8) No comment
DECLARE-TYPE-FREE:LEXICAL(9, unreleased) Yes comment
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE(2) Yes ---
DEFPACKAGE:ADDITION(7) Yes comment
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY(2) Yes comment
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES(3) Yes ---
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR(4) Yes ---
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE(4) Yes ---
DESCRIBE-INTERACTIVE:NO(4) No comment
DOTTED-MACRO-FORMS:ALLOW(3) Yes ---
EQUAL-STRUCTURE:STATUS-QUO(5) No comment
EXIT-EXTENT:MINIMAL(5) No comment
EXIT-EXTENT:MEDIUM(5) No comment
EXPT-RATIO:P.211(3) Yes ---
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION(4) Yes ---
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM(4) No ---
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN(2) Yes ---
FORMAT-PRETTY-PRINT:YES(7) Yes comment
FUNCTION-COMPOSITION:NEW-FUNCTIONS(4) Yes comment
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS(4) No comment
FUNCTION-DEFINITION:FUNCTION-SOURCE(2) Yes ---
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE(3) Yes ---
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE(5) Yes comment
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD(2) Yes comment
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER(7) Yes comment
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS(1) No comment
HASH-TABLE-TESTS:ADD-EQUALP(2) Yes comment
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY(4) Yes provisional
LAMBDA-FORM:NEW-MACRO(4) Yes ---
LCM-NO-ARGUMENTS:1(1) Yes ---
LISP-SYMBOL-REDEFINITION:DISALLOW(5) Yes provisional
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT(2) No comment
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE(2) Yes ---
NTH-VALUE:ADD(4) Yes comment
PACKAGE-CLUTTER:REDUCE(6) Yes comment
PACKAGE-DELETION:NEW-FUNCTION(5) Yes ---
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN(1) Yes ---
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR(3) Yes comment
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK(3) Yes ---
PROCLAIM-LEXICAL:LG(9) Yes comment
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER(3) Yes ---
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL(1) Yes ---
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE(6) Yes ---
REST-LIST-ALLOCATION:MAY-SHARE(3) Yes ---
REST-LIST-ALLOCATION:NEWLY-ALLOCATED(3) No ---
REST-LIST-ALLOCATION:MUST-SHARE(3) No ---
RETURN-VALUES-UNSPECIFIED:SPECIFY(6) Yes ---
ROOM-DEFAULT-ARGUMENT:NEW-VALUE(1) Yes ---
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS(3) No comment
SETF-PLACES:ADD-SETF-FUNCTIONS(1) No comment
SETF-SUB-METHODS:DELAYED-ACCESS-STORES(5) Yes ---
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS(8) Yes ---
STEP-ENVIRONMENT:CURRENT(3) Yes provisional
STREAM-ACCESS:ADD-TYPES-ACCESSORS(2) Yes comment
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS(2) No comment
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS(2) No comment
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS Yes provisional
SUBTYPEP-TOO-VAGUE:CLARIFY(4) Yes comment
SYMBOL-MACROLET-DECLARE:ALLOW(2) Yes ---
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM(5) Yes ---
TAGBODY-CONTENTS:FORBID-EXTENSION(5) Yes provisional
TAILP-NIL:T(5) Yes comment
TEST-NOT-IF-NOT:FLUSH-ALL(3) Yes provisional
TEST-NOT-IF-NOT:FLUSH-TEST-NOT(3) Yes provisional
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS(3) Yes provisional
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW(2) Yes ---
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE(3) Yes ---
---Detail---
Comment on ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9, 31-Oct-88)
We don't think the functions UPGRADED-ARRAY-ELEMENT-TYPE and
UPGRADED-COMPLEX-PART-TYPE are really necessary, but neither of us
cares enough to pursue that issue. Otherwise it looks ok.
Comment on DECLARE-FUNCTION-AMBIGUITY (Version 4, 05-Dec-88)
Moon is mildly opposed to this proposal, DELETE-FTYPE-ABBREVIATION,
because he sees it as gratuitously incompatible. Pitman favors the
proposal because he thinks the benefit of making things regular will
outweigh the costs.
Comment on DECLARE-TYPE-FREE (Version 8, 07-Dec-88)
Moon approved of an earlier version of this proposal, and wrote
a new option, LEXICAL, as part of a version 9 which has not been
released to X3J13. Both Moon and Pitman support the LEXICAL proposal,
version 9.
Comment on DEFPACKAGE (Version 7, 02-Nov-88)
The semantics should be defined in terms of the existing package
functions rather than being redundantly described, in order to minimize
the risk that DEFPACKAGE and the package functions will accidentally
differ in some unintended way.
Comment on DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2, 21-Sep-88)
The proposal should accomodate comments by IIM about some keywords
that were (presumably accidentally) not addressed
Comment on DESCRIBE-INTERACTIVE (Version 4, 15-Nov-88)
We prefer option EXPLICITLY-VAGUE.
We would vote "Yes" for the NO option iff EXPLICITLY-VAGUE fails.
Comment on EQUAL-STRUCTURE (Version 5, 01-Oct-88)
There are important technical comments about EQUALP which have not
been addressed, and which we feel must be addressed before this is
brought to a serious vote. Ultimately, when those pending technical
comments have been addressed, we expect to buy into this proposal.
Comment on EXIT-EXTENT (Version 5, 12-Dec-88)
Sadly, we feel it is still premature to vote on this issue at this time.
There are too many errors and inconsistencies in the writeup.
Comment on FORMAT-PRETTY-PRINT (Version 7, 15-Dec-88)
Although some fixes were made to accomodate ~R, some minor lingering
questions remain, which should be addressed under separate cover:
- Is PRINT-OBJECT used to print things of type FLOAT in any cases
where ~$, ~E, ~F, or ~G is used?
- Can users write any methods (including :AROUND, :BEFORE, etc) for
PRINT-OBJECT on type FLOAT?
If the answers to both of these questions end up being "Yes", then it
matters whether any of those format ops bind *PRINT-BASE* in order to
achieve the effect prescribed by CLtL of always printing floats in
base 10. If the answer to either of those questions is "No", then
it doesn't matter.
Comment on FUNCTION-COMPOSITION (Version 4, 12-Dec-88)
Barry Margolin's complaint about the degenerate case of COMPOSE should be
fixed in both proposals.
We prefer option NEW-FUNCTIONS.
We would vote "Yes" for COMPLEMENT-AND-ALWAYS iff NEW-FUNCTIONS fails.
Comment on FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5, 14-Nov-88)
It turns out the list type specifier being contemplated wouldn't have
helped the case of alternating keyword value pairs because `repetitions'
were not among the issues being addressed by those working on that topic.
Comment on GET-MACRO-CHARACTER-READTABLE (Version 2, 8-Dec-88)
The proposal is ok, but the test case is wrong and should definitely be
fixed before a vote is called. EQness of successive results from
GET-MACRO-CHARACTER when given the same arguments is not guaranteed
currently, and the new proposal does not suggest causing such a thing.
Comment on HASH-TABLE-PACKAGE-GENERATORS (Version 7, 08-Dec-88)
The test-package-iterator example has the values from the generator in
the wrong order. This should be fixed before the actual vote.
Comment on HASH-TABLE-STABILITY (Version 1, 11-Nov-88)
We believe that it is not appropriate to vote on this issue at this
time. Neither of us had the patience to figure out in enough detail
what it was saying to have any confidence in our opinions on the issue.
If there is really something important going on here, it should be
possible to say briefly and in plain English what the problem being
addressed is and what the nature of the solution is. If, after a brief,
intelligible, high level discussion of the issue, details must be
presented to back up the high level goals, that would be fine.
Comment on HASH-TABLE-TESTS (Version 2, 08-Dec-88)
We would really like to see = hash tables, too.
Provision on IN-PACKAGE-FUNCTIONALITY (Version 4, 12-Dec-88)
Our "Yes" vote is contingent on the DEFPACKAGE passing.
Provision on LISP-SYMBOL-REDEFINITION (Version 5, 22-Nov-88)
We're reluctant to include the paragraph about permitting (DEFVAR CAR ...).
Our vote is "Yes" only if the paragraph suggesting this is permissible
is removed.
Comment on MAKE-PACKAGE-USE-DEFAULT (Version 2, 08-Oct-88)
We oppose this issue because:
- It is not clearly in the best interest of programmers in a supposedly
portable language to give up the most convenient package creation
syntax to a non-portable purpose.
- The justifications given in the proposal are not strong enough to
support an incompatible change like this.
- This is a special-case hack that does not generalize. There is
no way to create a package based on the implementation-dependent
default -and- other packages.
- It would be just as easy for someone to say
:USE (PACKAGE-USE-LIST (FIND-PACKAGE "USER"))
At least this technique generalizes.
- The Rationale uses incorrect suppositions to arrive at a false
generalization. Cloe doesn't have the asymmetry referred to.
- The current practice is not correct.
No mention of what Cloe does is attempted.
- Even allowing the default to be controlled by a variable does
not help because it encourages programs to be developed depending
on defaults which are not part of those programs, and therefore
works against portability.
- The Discussion section does not correctly reflect discussion.
For example, Pitman has repeatedly voiced strong opposition.
The Discussion mentions neither the fact that he objected nor the
reasons for his objection.
Comment on NTH-VALUE (Version 4, 08-Dec-88)
The proposal should clarify the treatment of n when it is out of range.
Any non-negative integer index values should be permitted.
NIL should result if the index argument is too large.
Comment on PACKAGE-CLUTTER (Version 6, 12-Dec-88)
This leaves implementations freedom to hack any properties other than
those in the LISP, KEYWORD, and USER packages. In fact, though, the
user should probably also have rights over the system in packages he
creates.
This will be an incompatible change -- possibly a major one -- for
Genera, which uses properties named by keywords and by symbols in the
LISP package. However, we think the change is worthwhile.
In general, Genera tries not to distinguish "the system" from "the user".
Anything the system is permitted to do, the user is permitted to do.
As such, we feel a little odd about placing restrictions on the system
which are not likewise placed on the user. In fact, if the system can
cause problems in this way, the user can, too. This proposal is only
heuristic. We're voting "Yes" because it's probably a change for the
better. But we won't be surprised if ultimately it is not seen to be
the right way to achieve the high-level goal.
LEXICAL, TYPE, INLINE, NOTINLINE, and FTYPE proclamations should be
explicitly ruled out (just as SPECIAL is) except that TYPE is allowed
if it's a CL variable, and FTYPE, INLINE, and NOTINLINE are allowed
if it's a CL function.
The DECLARATION proclamation probably be explicitly allowed (because
we see no reason not to permit it).
Comment on PEEK-CHAR-READ-CHAR-ECHO (Version 3, 08-Oct-88)
There are some typos in this proposal that need to be corrected.
Also, IIM asked for a clarification which seemed reasonable to us.
Comment on PROCLAIM-LEXICAL (Version 9, 08-Dec-88)
The proposal might want to define the status of unproclaimed free variables.
Presumably, we should say that they are an error, and we should encourage
compilers to issue a warning.
Comment on SETF-FUNCTION-VS-MACRO (Version 3, 04-Nov-87)
We think it's premature to vote on this issue at this time.
We suggest that a better proposal, unifying this issue with SETF-PLACES,
should be produced either before or during the upcoming meeting.
Comment on SETF-PLACES (Version 1, 11-Nov-88)
We think it's premature to vote on this issue at this time.
We suggest that a better proposal, unifying this issue with
SETF-FUNCTION-VS-MACRO, should be produced either before or during
the upcoming meeting.
Provision on STEP-ENVIRONMENT (Version 3, 20-Jun-88)
We don't understand
"it is acceptable for an implementation to interactively step
through only those parts of the evaluation that are interpreted."
There are a variety of ways to clarify this that would satisfy us.
Still, this must be clarified so we can know for sure what we're voting
on and have some confidence that other implementors will interpret it
in the same way as we have before we can vote "Yes".
Comment on STREAM-ACCESS (Version 2, 30-Nov-88)
Although requiring types instead of predicates forces the implementation
of these streams as separate types, there is no obvious serious problem
which can result from that, and it leaves open the possibility of writing
methods on particular types -- if they are also classes -- are they? The
proposal should spell this out.
Having both the types and the predicates is unnecessary clutter.
Omitting the predicates makes for less overhead with no lost functionality.
Provision on STREAM-INFO (Version 6, 30-Nov-88)
We vote "Yes" only if the name-changing amendment mentioned in the mail passes.
Also, the writeup incorrectly states that Newline is not a standard character;
Perhaps someone has confused "standard" with "graphic".
Comment on SUBTYPEP-TOO-VAGUE (Version 4, 07-Oct-88)
Some minor worry about DECLARE-FUNCTION-AMBIGUITY here since the proposal
mentions the list form of the FUNCTION declaration.
This is a complicated issue and we have not had time to think it through
as fully as we might like to have. Still, insofar as we have studied it,
it looks ok.
Provision on TAGBODY-CONTENTS (Version 5, 09-Dec-88)
The term "data element" is too vague in paragraph 2 of the proposal.
Our "Yes" vote is contingent on correcting this.
Moon doesn't really like allowing ignored frobs other than expressions
and tags, but is willing to live with the current proposal.
There several typos which should be fixed.
Comment on TAILP-NIL (Version 5, 09-Dec-88)
The EQ -> EQL change at the last minute means this is not Genera current
practice, contrary to the current practice section.
Provision on TEST-NOT-IF-NOT (Version 2, 05-Oct-88)
We are mostly happy with either of these proposals, with slight
preference to FLUSH-ALL. However, our "Yes" vote is contingent on:
- changing "remove" to "deprecate", and coming up with a
suitable policy for deprecation which allows a comfortable
transition from current practice.
- either of the FUNCTION-COMPOSITION proposals passing.
Provision on TYPE-OF-UNDERCONSTRAINED (Version 3, 12-Dec-88)
Our "Yes" vote is contingent on the following issues being addressed:
- RANDOM-STATE should be added to the list of built-in types.
- (subtypep (type-of x) (class-of x)) => T T for all x, seems to have
been intended but is not actually said. It should be added.
- The implementation recommendation in the discussion about returning
only portable type specifiers should be discarded.
- Shouldn't this refer to classes with proper names rather than just
ones with names?
∂05-Jan-89 1313 CL-Cleanup-mailer Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 5 Jan 89 13:12:53 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA10957; Thu, 5 Jan 89 16:10:05 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA15055; Thu, 5 Jan 89 16:10:06 EST
Message-Id: <8901052110.AA15055@mist.>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
In-Reply-To: Your message of 12 Dec 88 18:16:00 -0800.
<881212-181649-5908@Xerox>
Date: Thu, 05 Jan 89 16:10:03 EST
From: Dan L. Pierson <pierson@mist.encore.com>
This is the official position of Encore Computer Corporation.
Y ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
Y ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
Y CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Version 5, 5-Dec-88, Mailed 5 Dec 88
Y CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
Y DECLARATION-SCOPE:NO-HOISTING
I DECLARATION-SCOPE:LIMITED-HOISTING
Version 4, 15-Nov-88, Mailed 9-Dec-88
I support LIMITED-HOISTING if NO-HOISTING fails. Either is better than
nothing.
Y DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Version 4, 5-Dec-88, Mailed 5-Dec-88
DECLARE-TYPE-FREE:ALLOW
N Version 8, 7-Dec-88, Mailed 9-Dec-88
Y Version 9, DECLARE-TYPE-FREE:ALLOW
N Version 9, DECLARE-TYPE-FREE:LEXICAL
Y DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
Y DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
Y DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
Y DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
Y DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
N DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
Y DESCRIBE-INTERACTIVE:NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
Y DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
Y EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
C EXIT-EXTENT:MINIMAL
C EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
There seems to be serious disagreement whether MEDIUM is implementable
as well as some serious dissatisfaction with MINIMAL. I oppose a vote
on this issue until it has either been reduced to a single proposal or
it has been reformed as two proposals that both sides agree are realistic
and implementable.
Y EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
Y FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
A FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Version 4, 7-Dec-88, Mailed 12-Dec-88
I think that tightening the definition of FIXNUM is a good thing, but don't
really care whether or not BIGNUM is tossed.
Y FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
Y FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
A FUNCTION-COMPOSITION:NEW-FUNCTIONS
Y FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
Y FUNCTION-DEFINITION:FUNCTION-SOURCE
Version 2, 09-Dec-88 , Mailed 9 Dec 88
Y FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
Y FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
Y GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
Y HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Version 7, 8-Dec-88, Mailed 9-Dec-88
A HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
The explanation seems reasonable and useful, but I'm agnostic about whether
it belongs in the standard.
Y HASH-TABLE-TESTS:ADD-EQUALP
Version 2, 8-Dec-88, Mailed 8 Dec 88
Y IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
A LAMBDA-FORM:NEW-MACRO
Version 4, 22-Nov-88, Mailed 8-Dec-88
Undecided would be better than abstain here, but that's not an option.
Y LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
Y LISP-SYMBOL-REDEFINITION:DISALLOW
Version 5, 22-Nov-88, Mailed 8 Dec 88
Y MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
Y MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
Y NTH-VALUE:ADD
Version 4, 8-Dec-88, Mailed 8 Dec 88
Y PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
Y PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
Y PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Version 1 27-Jun-88, Mailed 7 Oct 88
Y PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
Y PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
Y PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
Y RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Version 3, 9-Oct-88, Mailed 14-Oct-88
Y RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
Y REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
N REST-LIST-ALLOCATION:NEWLY-ALLOCATED
Y REST-LIST-ALLOCATION:MAY-SHARE
N REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
Y RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
Y ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
[The following are mutually exclusive]
Y SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
I SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
I support SETF-PLACES:ADD-SETF-FUNCTIONS if the first proposal
doesn't pass; it's ugly, but CLOS needs some resolution of this.
Y SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
Y STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
Y STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
Y STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
Y STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
Y SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
Y SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
Y SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
Y TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
Y TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
A TEST-NOT-IF-NOT:FLUSH-ALL
A TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
Cleaning up the sequence functions just isn't important enough to
justify incompatible changes at this time. With any luck new portable
series/iteration constructs will obsolete most of them instead. On
the other hand, I'd like to see them gone enough that I can't bring
myself to oppose the proposals either.
Y TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
Y UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
Y VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
∂05-Jan-89 1539 CL-Cleanup-mailer Issue: REST-LIST-ALLOCATION (Version 3)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Jan 89 15:39:31 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA12186@EDDIE.MIT.EDU>; Thu, 5 Jan 89 18:38:12 EST
Received: by spt.entity.com (smail2.5); 5 Jan 89 18:06:05 EST (Thu)
To: cl-cleanup@sail.stanford.edu
Subject: Issue: REST-LIST-ALLOCATION (Version 3)
Message-Id: <8901051806.AA14403@spt.entity.com>
Date: 5 Jan 89 18:06:05 EST (Thu)
From: gz@spt.entity.com (Gail Zacharias)
I would be (a little) more comfortable with MAY-SHARE if it explicitly stated
that the &rest argument is guaranteed to be a proper list. I know this is not
directly related to rest list sharing, but in practical terms I'm
concerned about the following situation:
(defun debugged-function (&rest args)
(declare (optimize (safety 0)))
... (cadr args) ...)
(apply #'debugged-function '(a . 17))
The error should be detected before debugged-function is called (or
put another way, whether this error is detected or not should be determined
by optimize settings in effect around apply, not in debugged-function).
∂05-Jan-89 1806 CL-Cleanup-mailer Ballot
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 5 Jan 89 18:05:54 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA10715; Thu, 5 Jan 89 18:07:44 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA08627; Thu, 5 Jan 89 18:04:25 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA08229; Thu, 5 Jan 89 18:05:29 PST
Date: Thu, 5 Jan 89 18:05:29 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901060205.AA08229@clam.sun.com>
To: cl-cleanup@sail.stanford.edu
Subject: Ballot
This is the official ballot for Sun Microsystems. I very much hope
that issues receiving significant opposition will be split out
from the block vote even if there is not a majority against.
Vote | Proposal
--------------------------------------------------------------------
Y | ARGUMENTS-UNDERSPECIFIED:SPECIFY
|
Y | ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
|
Y | CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
|
Y | CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
|
| DECLARATION-SCOPE:NO-HOISTING
If cases hoisted by 2nd alternatives are treated as errors and
limited-hoisting fails.
Y | DECLARATION-SCOPE:LIMITED-HOISTING
|
Y | DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
|
Y | DECLARE-TYPE-FREE:ALLOW
|
Y | DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
|
| DEFPACKAGE:ADDITION
If we allow time for more experimental usage of this before adopting it.
| DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
If the proposal is fixed as suggested by Kim Barrett.
Y | DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
|
Y | DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
|
N | DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
Y | DESCRIBE-INTERACTIVE:NO
|
Y | DOTTED-MACRO-FORMS:ALLOW
|
Y | EQUAL-STRUCTURE:STATUS-QUO
|
N | EXIT-EXTENT:MINIMAL
Y | EXIT-EXTENT:MEDIUM
|
Y | EXPT-RATIO:P.211
|
N | FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
This doesn't really do much for anyone and I believe it will break
some implementations. For portability use subranges of integer rather
than FIXNUM in declarations.
N | FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
|
Y | FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
|
Y | FORMAT-PRETTY-PRINT:YES
|
N | FUNCTION-COMPOSITION:NEW-FUNCTIONS
| FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
If a name better than "ALWAYS" can be found, or if only COMPLEMENT
were in the proposal.
Y | FUNCTION-DEFINITION:FUNCTION-SOURCE
|
Y | FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
|
Y | FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
|
Y | GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
|
Y | HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
|
N | HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
The problem statement hasn't yet compelled me to favor this.
Y | HASH-TABLE-TESTS:ADD-EQUALP
|
| IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
If we allow time for more experimental use of DEFPACKAGE before
adopting this.
N | LAMBDA-FORM:NEW-MACRO
Confusing to users.
Y | LCM-NO-ARGUMENTS:1
|
N | LISP-SYMBOL-REDEFINITION:DISALLOW
This appears to disallow too much.
N | MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
|
Y | MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
|
Y | NTH-VALUE:ADD
|
Y | PACKAGE-CLUTTER:REDUCE
|
A | PACKAGE-DELETION:NEW-FUNCTION
|
N | PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
No Unix convention I know of requires this new concept. Perhaps a
couple of good examples would convince me.
Y | PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
|
Y | PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
|
N | PROCLAIM-LEXICAL:LG
I don't believe in the reality of a separate "dynamic" environment,
don't believe it makes sense to support rapid access to
Globals on stock hardware, and don't understand what Scheme practices
don't work in Common Lisp. Perhaps I can be dissuaded about some or
all of these opinions.
Y | RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
|
Y | RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
|
N | REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Deprecate instead. Do not remove from the Lisp package.
N | REST-LIST-ALLOCATION:NEWLY-ALLOCATED
Y | REST-LIST-ALLOCATION:MAY-SHARE
N | REST-LIST-ALLOCATION:MUST-SHARE
|
Y | RETURN-VALUES-UNSPECIFIED:SPECIFY
|
N | ROOM-DEFAULT-ARGUMENT:NEW-VALUE
|
| SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
If SETF-PLACES:ADD-SETF-FUNCTIONS is deemed unsatisfactory by X3J13.
Y | SETF-PLACES:ADD-SETF-FUNCTIONS
|
N | SETF-SUB-METHODS:DELAYED-ACCESS-STORES
This does not seem to be the "right" choice of semantics, and I
believe that the presentation of the proposal needs substantial work
even if it is "right".
Y | STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
|
Y | STEP-ENVIRONMENT:CURRENT
|
Y | STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
|
Y | STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
but the language needs some way of controlling whether this
information is to be collected or not, for the benefit of
implementations that support this.
Y | SUBTYPEP-TOO-VAGUE:CLARIFY
|
Y | SYMBOL-MACROLET-DECLARE:ALLOW
|
Y | SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
|
Y | TAGBODY-CONTENTS:FORBID-EXTENSION
|
A | TAILP-NIL:T
|
N | TEST-NOT-IF-NOT:FLUSH-ALL
Perhaps deprecate these instead. They need to remain in the LISP
package. The functionality of REMOVE-IF-NOT is needed, perhaps use
the name KEEP-IF.
Y | TEST-NOT-IF-NOT:FLUSH-TEST-NOT
|
| TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
If the language in paragraph (a) is made clear. I can't tell which
"quantifiers" are intended or over what scope in the presentation.
Y | UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
|
Y | VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
|
∂05-Jan-89 2029 CL-Cleanup-mailer Issue PATHNAME-PRINT-READ, v1, and then some
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 5 Jan 89 20:29:41 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 256497; Thu 5-Jan-89 23:26:48 EST
Date: Thu, 5 Jan 89 23:26 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue PATHNAME-PRINT-READ, v1, and then some
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, IIM@ECLA.USC.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890104184739.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890106042619.9.GSB@GANG-GANG.SCRC.Symbolics.COM>
Date: Wed, 4 Jan 89 18:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Yes, hosting is an issue that I deliberately glossed in the proposal.
Let me say a few words about that and other issues that have been raised.
- I think #P is better than #. for the same reasons that Touretzky
proposed #H instead of relying on #. . That is, because most Lisp
data can be understood by engines considerably less complex than
Lisp itself. Lists, numbers, etc. are parseable and manipulable
[are those really words? I say them a lot but they look funny
written down..] by simpler programs which do not contain EVAL.
Using #. makes a large barrier to such programs in manipulating
any data involving pathnames, which a priori should not be an
opaque concept to non-Lisp programs.
. . .
I would strongly prefer that a more generic approach be taken to
allocating reader syntax.
Previously #S has been suggested as the obvious place for extensions
such as this to occur. In retrospect, I think that a slightly different
syntax should be reserved for extension by Common Lisp, in order that
any existing #S usage by particular implementations not conflict with
extensions dictated by CL.
e.g., if #T(typename ...) is reserved as the area of extension, then if
CL says that pathnames are read as #T(PATHNAME "namestring") there would
be no conflict for an implementation which happened to implement the
readableness of pathnames through the #S syntax already. Such an
implementation should print a pathname using #T(PATHNAME "namestring")
and read both its older #S(PATHNAME :name whatever ...) and the #T
syntax.
No implementation would be permitted to extend this syntax, therefore
there would never be any conflict when it is extended by CL.
Doing this does not preclude eventual expansion of a user's ability to
define #S syntax (something I think should be done). It DOES give CL a
place to expand read syntax into without using up all of the dispatch
characters, something which is beginning to look pretty likely.
∂06-Jan-89 0759 CL-Cleanup-mailer Re: Issue PATHNAME-PRINT-READ, v1, and then some
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 6 Jan 89 07:58:59 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA16559; Fri, 6 Jan 89 10:55:42 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA15499; Fri, 6 Jan 89 10:55:44 EST
Message-Id: <8901061555.AA15499@mist.>
To: "Glenn S. Burke" <gsb@ALDERAAN.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue PATHNAME-PRINT-READ, v1, and then some
In-Reply-To: Your message of Thu, 05 Jan 89 23:26:00 -0500.
<19890106042619.9.GSB@GANG-GANG.SCRC.Symbolics.COM>
Date: Fri, 06 Jan 89 10:55:41 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I would strongly prefer that a more generic approach be taken to
allocating reader syntax.
I agree. We really need to split the possible read macro characters
not given a meaning in CLtL into three groups:
1. Potential Common Lisp extensions. Your idea of #T as the only
hook here makes some sense.
2. Potential implementation extensions. I favor a small set of
of characters here as well.
3. Reserved for user extensions.
This isn't as easy as it may seem. One problem is what happens when a
popular user extension is incorporated in an implementation or even
standardized? The read-macro issues in Dick Waters' new pretty
printer are a good example; he uses #" as a read macro in a
particularly elegant way -and- this in conflict with currect practice
in KCL, which uses #" for pathnames.
At the least we need to officially recognize this problem and set some
guidelines for oursevles.
∂06-Jan-89 0919 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 1)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Jan 89 09:19:22 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA28373@EDDIE.MIT.EDU>; Fri, 6 Jan 89 12:17:54 EST
Received: by spt.entity.com (smail2.5); 6 Jan 89 11:44:25 EST (Fri)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 2 Jan 89 16:26 EST <19890102212611.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 1)
Message-Id: <8901061144.AA16434@spt.entity.com>
Date: 6 Jan 89 11:44:25 EST (Fri)
From: gz@spt.entity.com (Gail Zacharias)
Defstruct needs a :LOAD-FUNCTION (or whatever) option, and a rule for how
you get the simple slot-recreation function. I still think that it's going to
be awkward and confusing for this to default differently from :PRINT-FUNCTION
or :CONSTRUCTOR (both of which give you a default function if not specified),
but I guess nobody else does, so I won't press it...
I take it the form returned by MAKE-LOAD-FORM is walked again by the
file compiler, and it's the user's responsibility to avoid circularity
(as in (defmethod make-load-form ((x y)) `',x) or equivalent multi-level
examples). If so, this should be stated.
It would be useful to make the simple slot-recreation function available as
part of the language. Something like
(slot-reconstruct-form x) -> (make-instance '<class-name> :a <a> ...)
so they can do
(defmethod make-load-form ((x my-class)) (slot-reconstruct-form x))
The reason for this, aside from making things simpler for users doing
simple things, is that the obvious MAKE-LOAD-FORM doesn't work well with
inheritance. That is, if a user writes
(defclass person ()
((name :reader person-name)
(age :reader person-age)))
(defmethod make-load-form ((jrandom person))
`(make-instance ',(class-name (class-of jrandom))
:name ',(person-name jrandom)
:age ',(person-age jrandom)))
as recommended by the examples, and then does
(defclass astronaut (person)
((helmet-size :initarg 17)))
without specifing a make-load-form, then he's going to quietly lose dumping
astronauts in a very difficult to detect way.
∂06-Jan-89 1006 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Jan 89 10:06:01 PST
Received: by ti.com id AA02485; Fri, 6 Jan 89 12:03:52 CST
Received: from Kelvin by tilde id AA01454; Fri, 6 Jan 89 11:52:41 CST
Message-Id: <2809101212-8623747@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 6 Jan 89 11:53:32 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: gz@spt.entity.com (Gail Zacharias)
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: LOAD-OBJECTS (Version 1)
In-Reply-To: Msg of 6 Jan 89 11:44:25 EST (Fri) from gz@spt.entity.com (Gail Zacharias)
> Defstruct needs a :LOAD-FUNCTION (or whatever) option, and a rule for how
> you get the simple slot-recreation function.
Rather than adding more options to DEFSTRUCT, I'm more inclined to think
that the :PRINT-FUNCTION option is obsolete now that you can do
(DEFMETHOD PRINT-OBJECT ...)
> I still think that it's going to
> be awkward and confusing for this to default differently from :PRINT-FUNCTION
> or :CONSTRUCTOR (both of which give you a default function if not specified),
Maybe; on the Explorer, structures are already dumpable by treating them
like arrays, and I haven't noticed any problems caused by this.
∂06-Jan-89 1115 CL-Cleanup-mailer Issue FUNCTION-COMPOSITION
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 11:13:52 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA21890; Fri, 6 Jan 89 11:15:45 PST
Received: from clam.sun.com ([129.144.42.62]) by snail.Sun.COM (4.1/SMI-4.0)
id AA25862; Fri, 6 Jan 89 11:01:49 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA08876; Fri, 6 Jan 89 11:01:14 PST
Date: Fri, 6 Jan 89 11:01:14 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901061901.AA08876@clam.sun.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue FUNCTION-COMPOSITION
In the letter ballot I objected to the name "ALWAYS". I suggest
the name "CONSTANT-FN" as an alternative.
∂06-Jan-89 1438 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 1)
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 6 Jan 89 14:38:35 PST
Received: from GROUSE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 256772; Fri 6-Jan-89 17:37:12 EST
Date: Fri, 6 Jan 89 17:36 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 1)
To: CL-Cleanup@Sail.Stanford.EDU
cc: DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19890106223654.4.CASSELS@GROUSE.SCRC.Symbolics.COM>
Issue: REAL-NUMBER-TYPE
Forum: CLEANUP
References: Table 4-1.
Category: ADDITION
Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
and John Aspinall
Status: For Internal Discussion
Problem Description:
There is no standard type specifier symbol for the CL type
'(OR RATIONAL FLOAT).
Proposal (REAL-NUMBER-TYPE:REAL):
Add a standard type specifier
(REAL low high)
which means
(OR (RATIONAL low high) (FLOAT low high))
As with other such type specifiers, define that if the low and high
are omitted, the atomic specifier REAL may be used.
Clarify that NUMBER is equivalent to (OR REAL COMPLEX).
Proposal (REAL-NUMBER-TYPE:REALP):
Add a specific data type predicate REALP which tests for membership in
this type. [By analogy with NUMBERP.]
Test Case:
If a programmer wishes to test for "a number between 1 and 10", the
only current CL types would be '(or (rational 1 10) (float 1 10)) or
something like '(and numberp (not complexp) (satisfies range-1-10))
with (defun range-1-10 (real) (<= 1 real 10)). Both of these are
likely less efficient, and certainly less expressive than '(real 1 10).
Rationale:
Mathematics has a name for (OR RATIONAL FLOAT) -- it is "real".
This class is important because it is all the numbers which can be
ordered.
Throughout the "Numbers" chapter, the phrase "non-complex number" is
used.
MAX, MIN, p. 198 "The arguments may be any non-complex numbers."
CIS p. 207 "The argument ... may be any non-complex number."
Current Practice:
Probably nobody does this.
Cost to Implementors:
Some work is necessary to add this name. But since the underlying
type already exists the amount of work should be minimal.
Cost to Users:
Since this is an upward-compatible extension, it may be ignored by
users.
Cost of Non-Adoption:
Occassional inconvenience and/or inefficiency.
Benefits:
Mathematical clarity.
Ability to define CLOS class by the same name for the purpose of
method dispatch.
Aesthetics:
As mentioned under "rationale," this would be a more concise way to
express a common programming idiom.
Discussion:
The name "non-complex number" is incorrect because future
implementations may wish to include numerical types which are neither
complex nor real. [e.g. pure imaginary numbers or quaternions]
The name "scalar" is incorrect because the mathematical concept of
scalar may indeed include complex numbers.
Fortran and Pascal use the name "real" to mean what CL calls
SINGLE-FLOAT. That should cause no significant problem, since a Lisp
program written using the type REAL will do mathematically what the
equivalent Fortran program would do. This is because Fortran's "real"
data-type is a subtype of the CL REAL type. The only differences
might be that the Lisp program could be less efficient and/or more
accurate.
A survey of several Fortran and Pascal books shows that the distinction
between INTEGER and REAL is that REAL numbers may have fractional
parts, while INTEGERs do not. Later discussions explain that REALs
cover a greater range. Much later discussions cover precision
considerations, over/underflow, etc. So the average Fortran or Pascal
programmer should be completely comfortable with the proposed Lisp
concept of REAL.
∂06-Jan-89 1502 CL-Cleanup-mailer Re: Issue MACRO-FUNCTION-ENVIRONMENT, v1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:00:19 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JAN 89 19:56:54 PST
Date: 5 Jan 89 19:56 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue MACRO-FUNCTION-ENVIRONMENT, v1
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Wed, 4 Jan 89
13:59:03 PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890105-195654-180@Xerox>
I'm sorry, I should have caught this sooner. The following two issues were
passed at previous meetings (GET-SETF-METHOD-ENVIRONMENT and
MACRO-FUNCTION-ENVIRONMENT.)
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter
(no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
Version 2 29-May-87, extracted again
Version 3 5-Jun-87, by Masinter
Version 4 11-Jun-87, for release
Version 5 13-Jul-87, by Masinter
Problem Description:
If a macro that performs similar processing to SETF uses GET-SETF-METHOD,
and that macro occurs within a MACROLET, the expansion will not see the
MACROLET definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed explicitly
to denote the null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Clarify that, within the scope of a MACROLET, FLET and LABELS, global SETF
definitions of the name defined by the MACROLET, FLET or LABELS do not
apply. A SETF method applies only when the global function binding of the
name is lexically visible. All of the built in macros of Common Lisp
(SETF, INCF, DECF, POP, ROTATEF, etc.) which modify location specifications
obey this convention.
Test Case:
;;; This macro is like POP
(defmacro xpop (place &environment env)
(multiple-value-bind (dummies vals new setter getter)
(get-setf-method place env)
`(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
(prog1 (car ,(car new))
(setq ,(car new) (cdr ,(car new)))
,setter)))))
(defsetf frob (x) (value)
`(setf (car ,x) ,value))
;;; The following will modify (cdr z) and not (car z)
(macrolet ((frob (x) `(cdr ,x)))
(xpop (frob z)))
;;; The following is an error; an error may be signaled at macro expansion
time
(flet ((frob (x) (cdr x))
(xpop (frob z)))
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although some
do not. One implementation has extended GET-SETF-METHOD to take an optional
argument which is incompatible with this use.
Cost to implementors:
Some implementations will have to add this feature, although it is not a
major change.
Cost to users:
This is generally an upward compatible change. In implementations which did
not already take into account the lexical environment for SETF'd forms
might start working differently if the internal implementation of SETF is
changed. The likelihood of this affecting a user's program is very small.
Benefits:
This change improves portability and the ability to use MACROLET, FLET and
LABELS in portable code which might also have SETF forms.
Aesthetics:
SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more consistent
and correct.
Discussion:
The cleanup committee generally supports this change.
A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common Lisp
Object System) and should be addressed by a future proposal. For a while,
the cleanup committee attempted to deal with these issues together, but
decided to separate them out into their component parts. This issue is the
simplest.
- - - - - - - - - - - - - - - - - - - - - - - - - -
Issue: MACRO-FUNCTION-ENVIRONMENT
References: MACRO-FUNCTION, p. 144
MACROLET, pp. 113-4
&ENVIRONMENT, pp. 145-6
MACROEXPAND and MACROEXPAND-1, pp. 151-2
Category: ADDITION
Edit history: Version 1, Pavel, March 21, 1988
Version 2, Masinter, 8-Jun-88, (as per cleanup discussion)
Problem description:
The &ENVIRONMENT argument to a macro-expansion function may only be used as
the
second argument to the functions MACROEXPAND and MACROEXPAND-1. It is
sometimes
more convenient, however, to be able to work directly with the more
primitive
function MACRO-FUNCTION, on which MACROEXPAND and MACROEXPAND-1 are
presumably
based. However, since MACRO-FUNCTION does not take an environment
argument, it
cannot be used in situations in which that environment must be taken into
account.
Proposal (MACRO-FUNCTION-ENVIRONMENT:YES):
Add an optional second argument to MACRO-FUNCTION, that argument being an
environment that was passed as the &ENVIRONMENT argument to some macro
expansion
function. If the argument is not given, or the argument is NIL, the null
environment is used. MACRO-FUNCTION will now consider macro definitions
from
that environment in preference to ones in the global environment. It is an
error
to supply the environment argument in a use of MACRO-FUNCTION as a SETF
location
specifier.
Examples:
(macrolet ((foo (&environment env)
(if (macro-function 'bar env)
''yes
''no)))
(list (foo)
(macrolet ((bar () :beep))
(foo))))
=> (no yes)
(setf (macro-function 'bar env) ...) is an error.
Rationale:
Intuitively, the more primitive operation in macro expansion is
MACRO-FUNCTION,
not MACROEXPAND or MACROEXPAND-1, yet the environment argument can only be
supplied to the latter functions and not to the former one. By changing
this
state of affairs, the model of macro expansion becomes somewhat simpler.
Also,
more flexible use of the facility is enabled.
Current practice:
Xerox Common Lisp already implements this proposal. Symbolics Common Lisp,
and Kyoto Common Lisp do not. Lucid Common Lisp did not, but version 3.0
does.
Cost to Implementors:
This is presumably a simple change to make, a small matter of moving the
environment-searching code from MACROEXPAND-1 to MACRO-FUNCTION.
Cost to Users:
The change is upward-compatible and so poses no cost to users.
Cost of non-adoption:
One more (small) semantic wart on the language.
Benefits:
The function that users think of as being more primitive really is.
Aesthetics:
This slightly cleans up the language.
Discussion:
This issue was discussed starting in January 1987, but got tangled in
a web of other related proposals. In its current form, the only objections
have been that some other proposal or committee might otherwise change
macro handling, or that this proposal doesn't fix enough of the problems.
∂06-Jan-89 1502 CL-Cleanup-mailer environment argument for SUBTYPEP
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:02:30 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 89 20:28:15 PST
Date: 5 Jan 89 20:27 PST
From: masinter.pa@Xerox.COM
Subject: environment argument for SUBTYPEP
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Mon, 2 Jan 89
17:31:11 PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890105-202815-181@Xerox>
I'm temporarily blanking -- I can think of no way of making a local
declaration in such a way that SUBTYPEP might differ between local & global
context. So I can't think of a case where SUBTYPEP's results could
legitimately depend on an environment argument.
∂06-Jan-89 1503 CL-Cleanup-mailer Re: ballot
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:03:06 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 89 21:58:05 PST
Date: 5 Jan 89 21:57 PST
From: masinter.pa@Xerox.COM
Subject: Re: ballot
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
Tue, 3 Jan 89 16:05:56 MST
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890105-215805-189@Xerox>
STREAM-ACCESS had three proposals, but I left all but the first off the ballot.
You marked Y on ADD-TYPES-PREDICATES-ACCESSORS. Is your vote N on the other two proposals?
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
STREAM-ACCESS:ADD-TYPES-ACCESSORS
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
version 2, 30-Nov-88 mailed 9 Dec 88
Status: expect amendment T => "true"
∂06-Jan-89 1504 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:04:25 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 89 23:58:51 PST
Date: 5 Jan 89 23:57 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: PACKAGE-CLUTTER (Version 6)
To: cl-cleanup@sail.stanford.edu
From: Moon@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890105-235851-193@Xerox>
[lmm: I've been folding short comments into my Issue status file, but this
one is too long.]
This leaves implementations freedom to hack any properties other than
those in the LISP, KEYWORD, and USER packages. In fact, though, the
user should probably also have rights over the system in packages he
creates.
This will be an incompatible change -- possibly a major one -- for
Genera, which uses properties named by keywords and by symbols in the
LISP package. However, we think the change is worthwhile.
In general, Genera tries not to distinguish "the system" from "the user".
Anything the system is permitted to do, the user is permitted to do.
As such, we feel a little odd about placing restrictions on the system
which are not likewise placed on the user. In fact, if the system can
cause problems in this way, the user can, too. This proposal is only
heuristic. We're voting "Yes" because it's probably a change for the
better. But we won't be surprised if ultimately it is not seen to be
the right way to achieve the high-level goal.
LEXICAL, TYPE, INLINE, NOTINLINE, and FTYPE proclamations should be
explicitly ruled out (just as SPECIAL is) except that TYPE is allowed
if it's a CL variable, and FTYPE, INLINE, and NOTINLINE are allowed
if it's a CL function.
The DECLARATION proclamation probably be explicitly allowed (because
we see no reason not to permit it).
∂06-Jan-89 1506 CL-Cleanup-mailer Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:04:45 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 10:50:22 PST
Date: 6 Jan 89 10:48 PST
From: masinter.pa@Xerox.COM
Subject: Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
In-reply-to: Dan L. Pierson <pierson@mist.encore.com>'s message of Thu, 05
Jan 89 16:10:03 EST
To: Dan L. Pierson <pierson@mist.encore.com>
cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <890106-105022-239@Xerox>
The ballot incorrectly only listed one alternative of the three:
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
STREAM-ACCESS:ADD-TYPES-ACCESSORS
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
Do you prefer
Y STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
?
∂06-Jan-89 1503 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:03:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 89 22:14:46 PST
Date: 5 Jan 89 22:14 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 3 Jan 89 15:24 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890105-221446-191@Xerox>
The example I keep coming back to is one where it isn't so much that the
local declaration is easy to enforce as it is where it is difficult *not*
to enforce it.
Suppose I have
(defun frob (delta)
(flet ((more (x) (+ x delta)))
;; if you like, put (declare (inline more)) here
(typecase delta
(float (locally (declare (type float delta))
... (more rho ) ... )
((signed-byte 8)
(locally (declare (type (signed-byte 8) delta))
... (more zz) ... )
...)
Even without the inline, it is a common & legal transformation to do inline
substitution on "small" fletted functions. Even though the reference
"delta" in the definition of more isn't within the lexical scope of the
local declaration, it *is* the same delta. While its not impossible to
maintain a separate contour in order to segregate the type declarations, it
seems like unnecessary work, and in fact, the declaration is quite useful
if "more" is inlined.
∂06-Jan-89 1504 CL-Cleanup-mailer Issue APPLYHOOK-ENVIRONMENT (not submitted)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:03:58 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 89 23:11:08 PST
Date: 5 Jan 89 23:10 PST
From: masinter.pa@Xerox.COM
Subject: Issue APPLYHOOK-ENVIRONMENT (not submitted)
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Wed, 4 Jan 89
13:59:03 PST
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890105-231108-192@Xerox>
I can't find any issue to remove the ENV argument from APPLYHOOK, although
I remember the discussion of it (I think on the common lisp mailing list.).
I'm reserving issue name APPLYHOOK-ENVIRONMENT.
∂06-Jan-89 1504 CL-Cleanup-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:04:14 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JAN 89 23:55:12 PST
Date: 5 Jan 89 23:54 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)
To: cl-cleanup@sail.stanford.edu
From: Moon@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890105-235512-193@Xerox>
[lmm: I've been folding short comments into my Issue status file, but this
one is too long.]
We oppose this issue because:
- It is not clearly in the best interest of programmers in a supposedly
portable language to give up the most convenient package creation
syntax to a non-portable purpose.
- The justifications given in the proposal are not strong enough to
support an incompatible change like this.
- This is a special-case hack that does not generalize. There is
no way to create a package based on the implementation-dependent
default -and- other packages.
- It would be just as easy for someone to say
:USE (PACKAGE-USE-LIST (FIND-PACKAGE "USER"))
At least this technique generalizes.
- The Rationale uses incorrect suppositions to arrive at a false
generalization. Cloe doesn't have the asymmetry referred to.
- The current practice is not correct.
No mention of what Cloe does is attempted.
- Even allowing the default to be controlled by a variable does
not help because it encourages programs to be developed depending
on defaults which are not part of those programs, and therefore
works against portability.
- The Discussion section does not correctly reflect discussion.
For example, Pitman has repeatedly voiced strong opposition.
The Discussion mentions neither the fact that he objected nor the
reasons for his objection.
∂06-Jan-89 1504 CL-Cleanup-mailer Meeting in Hawaii
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:04:07 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 89 23:20:40 PST
Date: 5 Jan 89 23:20 PST
From: masinter.pa@Xerox.COM
Subject: Meeting in Hawaii
To: cl-cleanup@sail.stanford.edu
Message-ID: <890105-232040-193@Xerox>
OK:
Enough people can come Sunday that we'll meet Sunday afternoon to
decide/confirm what issues we will bring before the main X3J13 committee
for voting in plenary.
∂06-Jan-89 1526 CL-Cleanup-mailer Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:26:39 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA23600; Fri, 6 Jan 89 18:24:11 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA01261; Fri, 6 Jan 89 18:23:34 EST
Message-Id: <8901062323.AA01261@mist.>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
In-Reply-To: Your message of 06 Jan 89 10:48:00 -0800.
<890106-105022-239@Xerox>
Date: Fri, 06 Jan 89 18:23:32 EST
From: Dan L. Pierson <pierson@mist.encore.com>
The ballot incorrectly only listed one alternative of the three:
Oops, I noticed it, but forgot to put a note in my ballot. This is
the correct Encore vote:
Y STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
N STREAM-ACCESS:ADD-TYPES-ACCESSORS
N STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
I will consider voting for one of the alternatives if the combined one
looses, but haven't thought about which one I prefer.
∂06-Jan-89 1528 CL-Cleanup-mailer Re: Issue PATHNAME-PRINT-READ, v1
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:28:21 PST
Received: from relay2.cs.net by RELAY.CS.NET id af06590; 6 Jan 89 9:05 EST
Received: from draper.com by RELAY.CS.NET id aa27590; 6 Jan 89 8:38 EST
Date: Fri, 6 Jan 89 07:56 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue PATHNAME-PRINT-READ, v1
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
re: Richard Mlynarik's message about #S(PATHNAME ...)
Would this be legal? Does it imply that PATHNAME is implemented as a
DEFSTRUCT? Does the #S(PATHNAME "string" "another-string") syntax conflict
with #S(defstruct-structure :key value ...) syntax, or can it be analogous
to BOA-constructor structures? Whatever the case, I think it's far less
good idea to compromise #S this way than to "use up" #P, which Lucid is
already using anyhow.
∂06-Jan-89 1557 CL-Cleanup-mailer Issue FUNCTION-COMPOSITION
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:57:30 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516766; Fri 6-Jan-89 18:55:49 EST
Date: Fri, 6 Jan 89 18:55 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue FUNCTION-COMPOSITION
To: cperdue@Sun.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8901061901.AA08876@clam.sun.com>
Message-ID: <890106185519.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
I can't support any abbreviated name, and CONSTANT-FUNCTION is too long.
ALWAYS is at least current practice in an existing dialect.
However, if you really can't deal, how about CONSTANTLY.
(MAPCAR (CONSTANTLY 7) '(A B C)) => (7 7 7)
∂06-Jan-89 1618 CL-Cleanup-mailer Re: Issue FUNCTION-COMPOSITION
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 16:18:50 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA28487; Fri, 6 Jan 89 16:20:38 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA10478; Fri, 6 Jan 89 16:17:12 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA09453; Fri, 6 Jan 89 16:18:14 PST
Date: Fri, 6 Jan 89 16:18:14 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901070018.AA09453@clam.sun.com>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, cperdue@Sun.COM
Subject: Re: Issue FUNCTION-COMPOSITION
Cc: CL-Cleanup@SAIL.Stanford.EDU
CONSTANTLY? It's kind of catchy. I dunno. I just thought that
ALWAYS was confusing and we ought to be able to do better.
Sure, CONSTANTLY is OK with me.
-Cris
∂06-Jan-89 2117 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89 21:17:04 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516885; Sat 7-Jan-89 00:15:53 EST
Date: Sat, 7 Jan 89 00:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <12459458774.4.IIM@ECLA.USC.EDU>
Message-ID: <19890107051524.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon 2 Jan 89 17:31:11-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Proposal (SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT)
Extend SUBTYPEP to accept an optional third argument. This argument should be
either NIL, the &environment argument received by a macro expander function,
or the environment argument received by an *evalhook* or *applyhook* function.
This argument is used to distinguish between compile-time and run-time
environments.
I can't imagine why you would add an environment argument to SUBTYPEP,
but not to TYPEP. In any case, the CLOS plan for this was that anyone who
needed to use a non-null environment would call FIND-CLASS explicitly,
instead of relying on the implicit class inside TYPEP and SUBTYPEP.
Since use of the compile-time environment for types should be quite rare,
this was seen as much less of a burden than modifying existing functions
to take new optional arguments.
∂06-Jan-89 2125 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89 21:25:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516898; Sat 7-Jan-89 00:23:23 EST
Date: Sat, 7 Jan 89 00:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 1)
To: David N Gray <Gray@DSG.csc.ti.com>, Gail Zacharias <gz@spt.entity.com>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <2809101212-8623747@Kelvin>
Message-ID: <19890107052254.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 6 Jan 89 11:53:32 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> Defstruct needs a :LOAD-FUNCTION (or whatever) option, and a rule for how
> you get the simple slot-recreation function.
Rather than adding more options to DEFSTRUCT, I'm more inclined to think
that the :PRINT-FUNCTION option is obsolete now that you can do
(DEFMETHOD PRINT-OBJECT ...)
I agree. The old way using DEFSTRUCT options is so irregular and kludgy.
> I still think that it's going to
> be awkward and confusing for this to default differently from :PRINT-FUNCTION
> or :CONSTRUCTOR (both of which give you a default function if not specified),
Maybe; on the Explorer, structures are already dumpable by treating them
like arrays, and I haven't noticed any problems caused by this.
Since that's true in Symbolics Genera also, by reasoning from current practice
I could easily be convinced that the default method for STRUCTURE-OBJECT should
just save the structure name and slot values, rather than signalling an error.
That's fine for compatibility. What I really care about is that the default
method for STANDARD-OBJECT must signal an error.
∂06-Jan-89 2127 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89 21:27:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516901; Sat 7-Jan-89 00:26:41 EST
Date: Sat, 7 Jan 89 00:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 1)
To: Gail Zacharias <gz@spt.entity.com>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8901061144.AA16434@spt.entity.com>
Message-ID: <19890107052613.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 6 Jan 89 11:44:25 EST (Fri)
From: gz@spt.entity.com (Gail Zacharias)
I take it the form returned by MAKE-LOAD-FORM is walked again by the
file compiler, and it's the user's responsibility to avoid circularity
(as in (defmethod make-load-form ((x y)) `',x) or equivalent multi-level
examples). If so, this should be stated.
I'm not sure what "walked" means, but it wouldn't be useful if the form
returned by MAKE-LOAD-FORM wasn't allowed to contain objects for which
MAKE-LOAD-FORM must be called. Also you're right that if the user causes
infinite recursion the process won't terminate. We shouldn't assume the
reader can figure these things out on his own, so I'll say something when
I edit the writeup.
It would be useful to make the simple slot-recreation function available as
part of the language. Something like
(slot-reconstruct-form x) -> (make-instance '<class-name> :a <a> ...)
so they can do
(defmethod make-load-form ((x my-class)) (slot-reconstruct-form x))
The reason for this, aside from making things simpler for users doing
simple things, is that the obvious MAKE-LOAD-FORM doesn't work well with
inheritance. That is, if a user writes
(defclass person ()
((name :reader person-name)
(age :reader person-age)))
(defmethod make-load-form ((jrandom person))
`(make-instance ',(class-name (class-of jrandom))
:name ',(person-name jrandom)
:age ',(person-age jrandom)))
as recommended by the examples, and then does
(defclass astronaut (person)
((helmet-size :initarg 17)))
without specifing a make-load-form, then he's going to quietly lose dumping
astronauts in a very difficult to detect way.
I was thinking that CLOS metaobjects made slot-reconstruct-form so easy
to write on one's own that there was no reason to build it in. But perhaps
Gray's example shows that I was underestimating the complexity.
∂06-Jan-89 2246 CL-Cleanup-mailer Re: Ballot
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:45:27 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 11:32:34 PST
Date: 6 Jan 89 11:11 PST
From: masinter.pa@Xerox.COM
Subject: Re: Ballot
In-reply-to: cperdue@Sun.COM (Cris Perdue)'s message of Thu, 5 Jan 89
18:05:29 PST
To: cperdue@Sun.COM (Cris Perdue)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890106-113234-250@Xerox>
The ballot incorrectly listed only one of three alternatives:
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
STREAM-ACCESS:ADD-TYPES-ACCESSORS
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
Do you prefer the marked
Y | STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
?
∂06-Jan-89 2247 CL-Cleanup-mailer Issue: COMPILE-AND-LOAD-VERBOSITY????
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:46:14 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 16:33:37 PST
Date: 6 Jan 89 16:33 PST
From: masinter.pa@Xerox.COM
Subject: Issue: COMPILE-AND-LOAD-VERBOSITY????
To: cl-cleanup@sail.stanford.edu
Message-ID: <890106-163337-1447@Xerox>
I have this issue name down but no record of the discussion.
Synopsis: Need to clarify how much typeout is done when :VERBOSE is
specified to :COMPILE and :LOAD
Did I lose it? Is this really necessary?
∂06-Jan-89 2248 CL-Cleanup-mailer *DRAFT* issue status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:46:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 16:39:22 PST
Date: 6 Jan 89 16:38 PST
From: masinter.pa@Xerox.COM
Subject: *DRAFT* issue status
To: cl-cleanup@sail.stanford.edu
Message-ID: <890106-163922-1463@Xerox>
I sorted out the 7 ballots we've gotten so far, and tried to put together a
merged "status" list. I'm going thru my issue files once more
alphabetically, trying to get final or draft versions of things we want to
take with us -- not too much, I hope!
I haven't checked this, and I hope I didn't make too many mistakes.
Voters:
1 David N Gray (TI)
2 Kim A. Barrett (IIM)
3 David Bartley (TI)
4 Sandra J Loosemore (Utah)
5 David Moon (Symbolics)
6 Dan Pierson (Encore)
7 Chris Perdue (Sun)
In some cases I have changed a vote from Y to "I" (conditional) if the
comments said "Only if...." In a couple of cases I changed an "Abstain" to
"Conditional" where the associated comment warrented it.
ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 3, 2-Dec-88
Status: rewording to avoid "Status Quo" debate?
ALIST-NIL
Version 4, 1-Oct-88
Status: Withdrawn, recommend editorial
APPEND-ATOM
Version 1, 6-Dec-88
Synopsis: atom case of APPEND (left out of APPEND-DOTTED)
Status: Ready for release?
APPLYHOOK-ENVIRONMENT
Version 1, 6-Jan-89
Synopsis: remove (useless) env argument to applyhook
Status: Ready for release?
ARGUMENTS-UNDERSPECIFIED:SPECIFY
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Mailed 4 Dec 88
Vote: 1y2y3y4y5y6y6y
Status: part of "block" vote
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Mailed 5 Dec 88
Vote: 1y3y4y5y*6y6y
Comment: remove UPGRADED-ARRAY-ELEMENT-TYPE and UPGRADED-COMPLEX-PART-TYPE?
BACKQUOTE-COMMA-ATSIGN-DOT
Version 1, 22-Dec-88
Synopsis: `(... ,@x) vs `(... . ,x). Same, or different?
Status: Two proposals. Connection w/APPEND-DOTTED? Needs edits.
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, Mailed 5 Dec 88
Vote: 1y3y4y5y6y7y
α∂
CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 1, 6-Jan-89
Status: Too many proposals, not all there.
COERCE-INCOMPLETE (Version 2, 21-Nov-88)
Synopsis: Extend COERCE to handle default coercions? take an optional
FROM-TYPE?
Status: Not Ready
COMPILE-AND-LOAD-VERBOSITY
Synopsis: Need to clarify how much typeout is done when :VERBOSE is
specified to :COMPILE and :LOAD
Status: is there an issue?
COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
CONSTANT-SIDE-EFFECT (not submitted,???)
Synopsis: It is an error to do destructive operations on constants in code,
defconstant.
Status: In compiler?
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
Vote: 1n2y3n4y5y6y7y
DECLARATION-SCOPE:NO-HOISTING
Vote: 1n2n3n4y5n6y7i
DECLARATION-SCOPE:LIMITED-HOISTING
Vote: 1y2n3y4n5y6i7y
Version 4, 15-Nov-88, Mailed 9-Dec-88
Comment: "I really don't like NO-HOISTING because it is too imcompatible.
I think I
could live with LIMITED-HOISTING, but I'm unconvinced of the need for such
an
incompatible change. All of the problem examples are easily solved by
simply
changing some of the variable names."
6: "I support LIMITED-HOISTING if NO-HOISTING fails. Either is better
than
nothing."
7: "NO-HOISTING
If cases hoisted by 2nd alternatives are treated as errors and
limited-hoisting fails."
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Vote: 1n3y4y5y*6y7y
Version 4, 5-Dec-88, Mailed 5-Dec-88
Comment: 5: "Moon is mildly opposed to this proposal,
DELETE-FTYPE-ABBREVIATION,
because he sees it as gratuitously incompatible. Pitman favors the
proposal because he thinks the benefit of making things regular will
outweigh the costs."
DECLARE-TYPE-FREE:ALLOW
Vote: 1a3y4y5n*6n7y
Version 8, 7-Dec-88, Mailed 9-Dec-88
Comment: 5: DECLARE-TYPE-FREE:LEXICAL(9, unreleased) Yes.
6: Y Version 9, DECLARE-TYPE-FREE:ALLOW
N Version 9, DECLARE-TYPE-FREE:LEXICAL
DECLARE-TYPE-USER-DEFINED
Synopsis: allow (declare (type x y z)) for all valid type specifies type
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Vote: 1y3y4a5y6y7y
Version 2, 30-Sep-88, Mailed 6 Oct 88
DEFINITION-DELETE
Status: not submitted
DEFMACRO-BODY-LEXICAL-ENVIRONMENT
Synopsis: Allow DEFMACRO at non-top-level to capture environment. Not
submitted because "top level" wasn't defined.
Status: not submitted to cleanup; in compiler committee
DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
Vote: 1y3y4y5y*6y7i
Comment: 5: The semantics should be defined in terms of the existing
package
functions rather than being redundantly described, in order to minimize
the risk that DEFPACKAGE and the package functions will accidentally
differ in some unintended way.
7: "If we allow time for more experimental usage of this before adopting
it."
DEFSTRUCT-ACCESS-FUNCTIONS
Synopsis: defstruct accessors are proclaimed inline
Version 1, 5-Oct-88
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
Vote: 1y2i3y4y5y6y7i
Comment: "The proposal should accomodate comments by IIM about some
keywords
that were (presumably accidentally) not addressed "
7: "If the proposal is fixed as suggested by Kim Barrett"
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
Vote: 1Y2y3y4y5y6y7y
DEFSTRUCT-REDEFINITION (Version 1)
Status: Not released; need more options.
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
Vote: 1Y2y3y4y5y6y7y
DELETE-FILE-NONEXISTENT
Version 1, 5-Oct-88
Status: Needs work
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
Vote: 1n2a3n4n5y6n7n
DESCRIBE-INTERACTIVE:NO
Vote: 1y2y3y4y5n*6y7y
Version 4, 15-Nov-88, Mailed 7-Dec-88
Comment: "We prefer option EXPLICITLY-VAGUE.
We would vote "Yes" for the NO option iff EXPLICITLY-VAGUE fails."
DOTTED-MACRO-FORMS:ALLOW
Vote: 1y2y3y4y5y6y7y
Version 3, 15-Nov-88, Mailed 7-Dec-88
DYNAMIC-EXTENT (Version 2, 15-Nov-88)
Not Ready (?)
ELIMINATE-FORCED-CONSING
Version 3, 31-Aug-88
Status: Not Ready (?)
ENVIRONMENT-ENQUIRY
Synopsis: The environment inquiry functions (pp447-448) don't return a
value in consistent format across implementations. This makes
them virtually useless. I would like to constrain the values
enough so that implementors knew what to provide as return
values, and provide some examples of intended uses.
ERROR-NOT-HANDLED
Version 1, 25-Sep-88
EQUAL-STRUCTURE:STATUS-QUO
Vote: 1y2i3y4a5i*6y7y
Version 5, 1-Oct-88, Mailed 8 Oct 88
Comment: "There are important technical comments about EQUALP which have
not
been addressed, and which we feel must be addressed before this is
brought to a serious vote. Ultimately, when those pending technical
comments have been addressed, we expect to buy into this proposal."
EXIT-EXTENT:MINIMAL
Summary: What happens with non-local exits out of UNWIND-PROTECT cleanup
clauses?
Vote: 1a2n3a4n5n*6c7n
EXIT-EXTENT:MEDIUM
Vote: 1a2i3y4y5n*6c7y
Version 5, 12-Dec-88, Mailed 12-Dec-88
Status: serious mistakes as per moon, JonL says "not at this time"
Sadly, we feel it is still premature to vote on this issue at this time.
There are too many errors and inconsistencies in the writeup.
EXPT-RATIO:P.211
Vote: 1y2y4y5y6y7y
Version 3, 31-Oct-88, Mailed 7 Dec 88
FILE-LENGTH-PATHNAME
Status: not submitted "Some people didn't seem to think this was
appropriate. No one seemed very interested in writing it up."
FILE-WRITE-DATE-IF-NOT-EXISTS
Synopsis: What does FILE-WRITE-DATE do if no such file?
Version: no proposal
Status: "error signalling" committee
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
Vote: 1n2n3n4i5y6y7n
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Vote: 1y2n3y4y5n6a7n
Version 4, 7-Dec-88, Mailed 12-Dec-88
Comment: "TOSS-FIXNUM-TOSS-BIGNUM?"
4: "TIGHTEN-DEFINITION if TIGHTEN-FIXNUM-TOSS-BIGNUM is voted down"
FOLLOW-SYNONYM-STREAM
Status: Not Submitted; lost in STREAM-ACCESS
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Vote: 1y2y3y4a5y6y7y
Version 2, 2 Oct 88, Mailed 6 Oct 88
FORMAT-NEGATIVE-PARAMETERS
Version: No proposal
Status: "KMP will incorporate in the list-of-signals part of the signal
proposal"
FORMAT-PRETTY-PRINT:YES
Vote: 1y2y3y4y5y6y7y
Version 7, 15 Dec 88, Mailed 7 Dec 88
Comments: "Although some fixes were made to accomodate ~R, some minor
lingering
questions remain, which should be addressed under separate cover:
- Is PRINT-OBJECT used to print things of type FLOAT in any cases
where ~$, ~E, ~F, or ~G is used?
- Can users write any methods (including :AROUND, :BEFORE, etc) for
PRINT-OBJECT on type FLOAT?
If the answers to both of these questions end up being "Yes", then it
matters whether any of those format ops bind *PRINT-BASE* in order to
achieve the effect prescribed by CLtL of always printing floats in
base 10. If the answer to either of those questions is "No", then
it doesn't matter."
FORMAT-ROUNDING
Version 1, 5-Oct-88
FUNCTION-ARGUMENT-LIST
Synopsis: want way to get argument list
FUNCTION-COERCE-TIME (Version 2, 16-sep-88)
Not ready
FUNCTION-COMPOSITION:NEW-FUNCTIONS
Vote: 1n2n3n4n5y*6a7n
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Vote: 1n2y3n4y5i*6y
Version 4, 12 Dec 88, Mailed 12 Dec 88
Comments: "Barry Margolin's complaint about the degenerate case of COMPOSE
should be
fixed in both proposals."
6: "We would vote "Yes" for COMPLEMENT-AND-ALWAYS iff NEW-FUNCTIONS
fails."
FUNCTION-DEFINITION:FUNCTION-SOURCE
Vote: 1y3y4y5y6y7y
Version 2, 09-Dec-88 , Mailed 9 Dec 88
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Mailed 12-Dec-88
Vote: 1y2y3y4y5y6y7y
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Vote: 1y2n3y4a5y*6y7y
Version 5, 14-Nov-88, Mailed 8-Dec-88
Comments: "It turns out the list type specifier being contemplated wouldn't
have
helped the case of alternating keyword value pairs because `repetitions'
were not among the issues being addressed by those working on that topic."
GC-MESSAGES
Version 2, 14-Nov-88
GET-MACRO-CHARACTER-DISPATCHING
What does GET-MACRO-CHARACTER return for dispatching macros?
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Vote: 1y3y4y5y*6y7y
Version 2, 8 Dec 88, Mailed 8 Dec 88
Comments: "The proposal is ok, but the test case is wrong and should
definitely be
fixed before a vote is called. EQness of successive results from
GET-MACRO-CHARACTER when given the same arguments is not guaranteed
currently, and the new proposal does not suggest causing such a thing."
HASH-TABLE-ACCESS (Version 2, 13 Oct 88)
PROVIDE
Not ready
HASH-TABLE-GC (no proposal)
Will not be
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Vote: 1a3a4n5y*6y7y
Version 7, 8-Dec-88, Mailed 9-Dec-88
Comments: "The test-package-iterator example has the values from the
generator in
the wrong order. This should be fixed before the actual vote."
HASH-TABLE-PRINTED-REPRESENTATION (Version 2)
Not ready (new proposal from KMP?)
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Vote: 1a2y3y4c5n*6a7n
Version 1, 11-Nov-88 , Mailed 12 Dec 88
Discussion: "It isn't clear that this is necessary, but I won't oppose
it if other people think it is important."
"I agree with the sentiments expressed in the "additional comment"
at the end. I'd rather see a shorter proposal that deals only
with destructive operations on keys."
"We believe that it is not appropriate to vote on this issue at this
time. Neither of us had the patience to figure out in enough detail
what it was saying to have any confidence in our opinions on the issue.
If there is really something important going on here, it should be
possible to say briefly and in plain English what the problem being
addressed is and what the nature of the solution is. If, after a brief,
intelligible, high level discussion of the issue, details must be
presented to back up the high level goals, that would be fine."
HASH-TABLE-TESTS:ADD-EQUALP
Vote: 1y3y4n5y*6y7y
Version 2, 8-Dec-88, Mailed 8 Dec 88
Comment: "We would really like to see = hash tables, too."
IEEE-ATAN-BRANCH-CUT
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Vote: 1y2y3y4n5y6y7i
Version 4, 12-Dec-88, Mailed 12-Dec-88
Discussion: "Our "Yes" vote is contingent on the DEFPACKAGE passing."
"If we allow time for more experimental use of DEFPACKAGE before
adopting this."
IN-SYNTAX
Synopsis: IN-PACKAGE for readtables
Version 1, 21-Oct-88
INPUT-STREAM-P-CLOSED
Version: not submitted
Synopsis: What do INPUT-STREAM-P and OUTPUT-STREAM-P do on closed streams?
INPUT-STREAM-P-EXAMPLE
Version 1, 26-Oct-88
LAMBDA-FORM:NEW-MACRO
Vote: 1y3y4n5y6a7n
Version 4, 22-Nov-88, Mailed 8-Dec-88
LAMBDA-LIST-DUPLICATES
withdrawn
LCM-NO-ARGUMENTS:1
Vote: 1y3y4y5y6y7y
Version 1, 17 Oct 88, Mailed 8 Dec 88
LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION
Status: Not yet submitted
Synopsis: should LEAST-POSITIVE- and MOST-POSITIVE-XXX-FLOAT numbers
include denormalized ones in those implementations that admit them?
LET-TOP-LEVEL
Synopsis: What's top level?
Status: => clcompiler
LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88
LISP-SYMBOL-REDEFINITION:DISALLOW
Vote: 1y3y4y5i6y7n
Version 5, 22-Nov-88, Mailed 8 Dec 88
Comment: "We're reluctant to include the paragraph about permitting (DEFVAR
CAR ...).
Our vote is "Yes" only if the paragraph suggesting this is permissible
is removed."
LIST-TYPE-SPECIFIER (Version 1)
no new version?
LOAD-OBJECTS
Version 1, 2-Jan-89
Synopsis: "Provide a way to allow defstruct/defclass objects in compiled
files"
LOAD-TIME-EVAL
Synopsis: #, semantics not in read macro
Status: => clcompiler
LOAD-TRUENAME
MAKE-CONCATENATED-STREAM-EXAMPLE
Version 1, 26-Oct-88
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Vote: 1y2n3y4n5n*6y7n
Version 2, 8 Oct 88, Mailed 12-Dec-88
Comment: lengthy
MAKE-STRING-FILL-POINTER
Version 1, 20-Oct-88
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Vote: 1y2y3y4y5y6y7y
Version 2, 09-Jun-88, Mailed 8 Oct 88
NTH-VALUE:ADD
Vote: 1a3n4n5y*6y7y
Version 4, 8-Dec-88, Mailed 8 Dec 88
Discussion: "OK, but of marginal value."
The proposal should clarify the treatment of n when it is out of range.
Any non-negative integer index values should be permitted.
NIL should result if the index argument is too large.
OUTPUT-STREAM-P-EXAMPLE
Version 1, 26-Oct-88
PACKAGE-CLUTTER:REDUCE
Vote: 1y2y3y4i5y6y7y
Version 6, 12-Dec-88, Mailed 12-Dec-881
Discussion: stronger on properties; bugs
"I don't see any need to restrict the use of internal symbols in
the LISP package as property indicators. Otherwise I support the
proposal."
PACKAGE-DELETION:NEW-FUNCTION
Vote: 1y3y4a5y6y7a
Version 5, 21 nov 88, Mailed 8 Dec 88
minor glitches
PACKAGE-FUNCTION-CONSISTENCY
Version 1, 21-Oct-88
PATHNAME-CANONICAL-TYPE
Status: => "pathname" committee
PATHNAME-COMPONENT-CASE
Status: => "pathname" committee
PATHNAME-LOGICAL
Status: => "pathname" committee
PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Status: expand current practice?
PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Status: => "pathname" committee
PATHNAME-SYNTAX-ERROR-TIME
Status: => "pathname" committee
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Vote: 1y3y4i5y6y7n
Version 1 27-Jun-88, Mailed 7 Oct 88
Comment: ":UNSPECIFIC should be legal in all pathname fields, not just in
the
type field."
"No Unix convention I know of requires this new concept. Perhaps a
couple of good examples would convince me."
PATHNAME-WILD
Status: => "pathname" committee
PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: How to deal with logical devices, :unspecific components, etc in
pathname functions
Status: PATHNAME-TYPE-UNSPECIFIC handled part, rest not yet submitted =>
"pathname"
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Synopsis: interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM
Vote: 1y2y3y4n5y*6y7y
Version 3, 8-Oct-88, Mailed 8 Oct 88
Comment: "All metastreams must now support PEEK-CHAR directly..."
"This proposal seems to be in conflict with the rationale for
issue UNREAD-CHAR-AFTER-PEEK-CHAR, which is to legitimize
implementing PEEK-CHAR as READ-CHAR/UNREAD-CHAR."
"There are some typos in this proposal that need to be corrected.
Also, IIM asked for a clarification which seemed reasonable to us."
PRINT-CIRCLE-SHARED
Status: Not submitted
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Vote: 1y3y4i5y6y7y
Version 3, 20 Sep 88, Mailed 8 Oct 88
Comment: This proposal would be OK if it specified that circularity only
had to be detected for objects that are contained in slots of the
structure, not random objects that are printed out by the structure
print function. Rationale: an obvious way to handle circular
printing is to traverse the structure to detect circularities before
printing anything."
PROCLAIM-LEXICAL:LG
Synopsis: add LEXICAL proclaimation
Vote: 1n3c4n5y*6y7n
Version 9, 8-Dec-88, Mailed 12-Dec-88
Discussion: change "Clarify" => "Define"
"This sounds like basically a good idea, but there appears
to be insufficient experience with actually implementing
and using it for it to be ready for standardization."
"I favor this in principle, but I want some discussion to
ensure that we're all talking about the same thing."
"I don't have any fundamental complaint with this issue, but I believe
we need more experience with this feature before it should be
standardized."
"The proposal might want to define the status of unproclaimed free
variables.
Presumably, we should say that they are an error, and we should encourage
compilers to issue a warning."
"I don't believe in the reality of a separate "dynamic" environment,
don't believe it makes sense to support rapid access to
Globals on stock hardware, and don't understand what Scheme practices
don't work in Common Lisp. Perhaps I can be dissuaded about some or
all of these opinions."
PROCLAIM-SCOPE
Status: => clcompiler
PROMPT-FOR
Status: awaiting resubmission
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Vote: 1y3y4y5y6y7y
Version 3, 9-Oct-88, Mailed 14-Oct-88
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Vote: 1y2y3y4y5y6y7y
Version 1, 14-Sep-88, Mailed 7 Oct 88
READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Status: Not submitted
READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
REMF-MULTIPLE
Synopsis: What does REMF do if it sees more than one INDICATOR?
Status: Not ready
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Vote: 1y2y3y4y5y6y7n
Version 6, 9 Dec 88, mailed 09 Dec 88
Comment: "Deprecate instead. Do not remove from the Lisp package."
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
Vote: 1n2n3n4n5n6n7n
REST-LIST-ALLOCATION:MAY-SHARE
Vote: 1y2y3y4y5y6y7y
REST-LIST-ALLOCATION:MUST-SHARE
Vote: 1n2n3n4n5n6n7n
Version 3, 12-Dec-88, mailed 12-Dec-88
Discussion: Add a new kind of declaration
REST-LIST-EXTENT
Status: incorporated in issue DYNAMIC-EXTENT
RETURN-VALUES-UNSPECIFIED:SPECIFY
Vote: 1y3y4y5y6y
Version 6, 9 Dec 88 mailed 9-Dec-88
ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Vote: 1y2y3y4a5y6y
Version 1 12-Sep-88 mailed 8 Oct 88
Comment: "I liked KMP's suggestion of defining additional synonyms"
[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Vote: 1y3y4n5n*6y7i
Version 3, 4-Nov-87, mailed Nov 87
Comment: "We think it's premature to vote on this issue at this time.
We suggest that a better proposal, unifying this issue with SETF-PLACES,
should be produced either before or during the upcoming meeting."
7: "If SETF-PLACES:ADD-SETF-FUNCTIONS is deemed unsatisfactory by X3J13"
SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 1, 5-Dec-88
SETF-PLACES:ADD-SETF-FUNCTIONS
Vote: 1n3n4i5n*6i7y
Version 1, 11-Nov-88, mailed 9-Dec-88
Discussion: other options? (Comments)
"We think it's premature to vote on this issue at this time.
We suggest that a better proposal, unifying this issue with
SETF-FUNCTION-VS-MACRO, should be produced either before or during
the upcoming meeting."
SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Synopsis: more careful definition of order of evaluation inside (SETF (GETF
...) ...)
Vote: 1a2y4y5y6y7n
Version 5, 12-Feb-88 mailed 8 Oct 88
7: "This does not seem to be the "right" choice of semantics, and I
believe that the presentation of the proposal needs substantial work
even if it is "right".
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Version 6, 06-Oct-88
Status: New version scales down rejected version
SINGLE-FLOAT-NON-PORTABLE
Status: Not yet submitted
Synopsis: should single-float and double-float be removed from the
standard?
SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Status: superceded by DECLARE-TYPE-FREE?
SPECIAL-VARIABLE-TEST
Status: "On hold pending SYNTACTIC-ENVIRONMENT-ACCESS"
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Vote: 2y3y4y5y6y7y
Version 8, 8 Jul 88, Mailed 7 Oct 88
STANDARD-VALUE
Synopsis: specify way to communicate from user programs to REP loops when
binding is "temporary"
Version 1, 21-Oct-88
STEP-ENVIRONMENT:CURRENT
Vote: 1y2c3y4y5i6y7y
Version 3, 20-Jun-88, mailed 7 Oct 88
Comment: "We don't understand
"it is acceptable for an implementation to interactively step
through only those parts of the evaluation that are interpreted."
There are a variety of ways to clarify this that would satisfy us.
Still, this must be clarified so we can know for sure what we're voting
on and have some confidence that other implementors will interpret it
in the same way as we have before we can vote "Yes".
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
Vote: 1n3n4i5n*6y
STREAM-ACCESS:ADD-TYPES-ACCESSORS
Vote: 1n3n4?5y*6?
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
Vote: 1y3y4?5n*6?
version 2, 30-Nov-88 mailed 9 Dec 88
Status: expect amendment T => "true"
Comment: "Although requiring types instead of predicates forces the
implementation
of these streams as separate types, there is no obvious serious problem
which can result from that, and it leaves open the possibility of writing
methods on particular types -- if they are also classes -- are they? The
proposal should spell this out.
Having both the types and the predicates is unnecessary clutter.
Omitting the predicates makes for less overhead with no lost
functionality.
STREAM-CAPABILITIES
Status: => "pathname" committee
STREAM-DEFINITION-BY-USER
Synopsis: Need a way to define user-defined streams.
STREAM-ELEMENT-TYPE-EXAMPLES
Status: ?? missing proposal
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Vote: 1y3y4y5i*6y7y
Version 6, 30-Nov-88, mailed 9 dec 88
Status: expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
Comment: 5: We vote "Yes" only if the name-changing amendment mentioned in
the mail passes.
Also, the writeup incorrectly states that Newline is not a standard
character;
Perhaps someone has confused "standard" with "graphic".
SUBTYPEP-TOO-VAGUE:CLARIFY
Vote: 1y2y3y5y*6y7y
Version 4, 7-Oct-88, mailed 7 Oct 88
Comment: "Some minor worry about DECLARE-FUNCTION-AMBIGUITY here since the
proposal
mentions the list form of the FUNCTION declaration. This is a complicated
issue and we have not had time to think it through as fully as we might
like to have. Still, insofar as we have studied it, it looks ok."
SYMBOL-MACROFLET
Version 1
???
SYMBOL-MACROLET-DECLARE:ALLOW
Vote: 1y3y4i5y6y7y
Version 2, 9-Dec-88, mailed 9 Dec 88
Comment: 4: "Only if SYMBOL-MACROLET-SEMANTICS passes"
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Vote: 1y2y3y4a5y6y7y
Version 5, 30-Nov-88, mailed 9 Dec 88
SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
=> clcompiler
TAGBODY-CONTENTS:FORBID-EXTENSION
Vote: 1y3y4y5i6y7y
Version 5, 9-Dec-88 mailed 9 Dec 88
Comment: "The term "data element" is too vague in paragraph 2 of the
proposal.
Our "Yes" vote is contingent on correcting this. Moon doesn't really like
allowing ignored frobs other than expressions and tags, but is willing to
live with the current proposal."
TAIL-RECURSION-OPTIMIZATION (Version 2)
Status: Not Ready
TAILP-NIL:T
Synopsis: Operation of TAILP given NIL
Vote: 1y2y3y4y5y*6y7a
Version 5, 9-Dec-88, mailed 12-Dec-88
Discussion: Current practice is wrong. Expand to LDIFF? Add :TEST?
"The EQ -> EQL change at the last minute means this is not Genera current
practice, contrary to the current practice section."
TEST-NOT-IF-NOT:FLUSH-ALL
Vote: 1n3n4y5y*6a7n*
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Vote: 1n3n4i5y*6a7y
Version 3, 1 Dec 88 mailed 9 dec
Comment: "Unnecessary incompatible change."
4: "Flushing some is better than not flushing all"
5: "We are mostly happy with either of these proposals, with slight
preference to FLUSH-ALL. However, our "Yes" vote is contingent on:
- changing "remove" to "deprecate", and coming up with a
suitable policy for deprecation which allows a comfortable
transition from current practice.
- either of the FUNCTION-COMPOSITION proposals passing.
7: Perhaps deprecate these instead. They need to remain in the LISP
package. The functionality of REMOVE-IF-NOT is needed, perhaps use
the name KEEP-IF."
"
THE-AMBIGUITY
Version 1, 21-Oct-88
Status: typo
TRACE-ERROR
Version 1
Status: withdrawn?
TRACE-FUNCTION-ONLY (withdrwan)
TRUENAME-SYNTAX-ONLY
Status: => "pathname" committee
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Vote: 1y2c3y4y5i6y7i
Version 3, 12-Dec-88, mailed 12 Dec 88
Discussion: some "bugs" in the proposal
5: "Our "Yes" vote is contingent on the following issues being addressed:
- RANDOM-STATE should be added to the list of built-in types.
- (subtypep (type-of x) (class-of x)) => T T for all x, seems to have
been intended but is not actually said. It should be added.
- The implementation recommendation in the discussion about returning
only portable type specifiers should be discarded.
- Shouldn't this refer to classes with proper names rather than just
ones with names?
7: If the language in paragraph (a) is made clear. I can't tell which
"quantifiers" are intended or over what scope in the presentation.
TYPE-SPECIFIER-PREDICATE
Status: Not yet submitted
Synopsis: "Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time."
UNDEFINED-VARIABLES-AND-FUNCTIONS
Version 1, 29-Nov-88
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Vote: 1y2y3y4y5y6y7y
Version 2, 2-Dec-88, mailed 12-Dec-88
UNWIND-PROTECT-NON-LOCAL-EXIT
Status: renamed to EXIT-EXTENT
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Vote: 1y3y4y5y6y7y
Version 3, 08-Oct-88, mailed 9 Dec 88
WRITE-NEWLINE
Status: Not submitted
∂06-Jan-89 2246 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:45:31 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 89 11:48:01 PST
Date: 6 Jan 89 11:37 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 2 Dec 88 05:23 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.edu
Message-ID: <890106-114801-253@Xerox>
I'd like to see the following changes to the proposal:
a) I don't like saying that the effect of adjusting an array which "is not
adjustable" is not defined. I don't see any reason not to say that it
signals an error.
b) I like defining clearly that "is not adjustable" means
"ADJUSTABLE-ARRAY-P returns false", and clarifying that MAKE-ARRAY may
return an adjustable array even if the :ADJUSTABLE array is given NIL.
c) I would like to say that either all arrays are adjustable, or else only
those that are specified with :ADJUSTABLE true, and that a conformal
implementation will document which behavior it uses.
d) Rename the proposal name from "STATUS-QUO" to "MAY-BE-ADJUSTABLE" and
change "Document clearly" to "Specify".
Is this OK?
∂06-Jan-89 2246 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:45:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 89 11:16:35 PST
Date: 6 Jan 89 11:06 PST
From: masinter.pa@Xerox.COM
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 5)
In-reply-to: cperdue@Sun.COM (Cris Perdue)'s message of Thu, 5 Jan 89
18:05:29 PST
To: cperdue@Sun.COM (Cris Perdue)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890106-111635-248@Xerox>
On your ballot, Sun commented "This appears to disallow too much."
What things would you allow that are disallowed by this proposal?
∂06-Jan-89 2247 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:45:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 14:54:13 PST
Date: 6 Jan 89 14:51 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REAL-NUMBER-TYPE (version 1)
In-reply-to: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 6 Jan 89 17:36 EST
To: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@Sail.Stanford.EDU, DySak@STONY-BROOK.SCRC.Symbolics.COM,
JGA@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890106-145413-1224@Xerox>
The proposal should make REAL a CLOS class too, I think, rather than just
allowing that to be done.
∂06-Jan-89 2247 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:45:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 89 11:58:01 PST
Date: 6 Jan 89 11:57 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
In-reply-to: CL-Cleanup@Sail.Stanford.edu's message of 5 Dec 88 11:45 PST
To: cl-cleanup@Sail.Stanford.Edu
cc: masinter.pa@Xerox.COM
Message-ID: <890106-115801-255@Xerox>
The proposal contains the sentence
'Eliminate the distinction between types "for declaration" and "for
discrimination".'
However, the distinction remains for the list form of the FUNCTION type
specifier, which is only valid "for declaration".
I don't think the proposal removes the list form of the FUNCTION type
specifier, or (alternatively, magically) allows the list form of the
FUNCTION type specifier to be used for discrimination. I think the sentence
needs to be qualified that it applies to COMPLEX and ARRAY and VECTOR type
specifiers.
I concur with the sentiment that would like to see the proposal amended to
remove UPGRADED-COMPLEX-PART-TYPE and UPGRADED-ARRAY-ELEMENT-TYPE, as they
are of so extremely limited utility and can be written trivially if really
necessary.
Stylisticly, this can be accomplished quickly if a bit awkwardly, by saying
"The proposal is written using the following two functions, although these
functions are not added to the standard."
∂06-Jan-89 2247 CL-Cleanup-mailer Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:45:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 89 14:04:22 PST
Date: 6 Jan 89 14:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Fri, 30 Dec 88
02:31:41 PST
To: Jon L White <jonl@lucid.com>
cc: Gray@DSG.csc.ti.com, KMP@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890106-140422-1103@Xerox>
I fail to see the necessity of correlating the behavior of backquote with
the behavior of APPEND, since we've not ever specified that backquote
actually has to use APPEND. If your backquote currently uses APPEND, make
it use BACKQUOTE-APPEND instead which has some other semantics than APPEND.
∂06-Jan-89 2247 CL-Cleanup-mailer Issue: APPLYHOOK-ENVIRONMENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:45:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 11:50:58 PST
Date: 6 Jan 89 11:49 PST
From: masinter.pa@Xerox.COM
Subject: Issue: APPLYHOOK-ENVIRONMENT (Version 1)
To: cl-cleanup@sail.stanford.edu
Message-ID: <890106-115058-253@Xerox>
!
Forum: Cleanup
Issue: APPLYHOOK-ENVIRONMENT
References: APPLYHOOK (CLtL p. 323)
Category: CHANGE
Edit history: Masinter, 6-Jan-89, Version 1
Problem description:
The function APPLYHOOK is documented to take an optional environment
argument. CLtL says "Furthermore, the env argument is used as the lexical
environment for the operation; env defaults to the null environment."
However, there is no way that the lexical environment can effect the way in
which APPLYHOOK processes its arguments; it merely calls the specified
function, and function call is not affected by lexical environments. (The
"function" argument to APPLYHOOK is a function object.)
This has been regularly a source of confusion for programmers encountering
APPLYHOOK.
Proposal (APPLYHOOK-ENVIRONMENT:REMOVE-ENV): Remove the optional "ENV"
argument to applyhook.
Rationale:
Removes a very minor wart.
Current practice:
Most implementations accept an extra argument and then ignore it.
Cost to Implementors:
Remove optional ENV argument from APPLYHOOK and any code that passes one to
APPLYHOOK.
Cost to Users:
Remove any ENV argument passed to APPLYHOOK.
Cost of non-adoption:
Continued confusion.
Performance impact:
None
Benefits:
Removes a wart.
Esthetics:
Minor improvement.
Discussion:
This was discussed on the Common Lisp mailing list several years ago, but
slipped thru the cracks.
∂06-Jan-89 2247 CL-Cleanup-mailer Re: Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:46:01 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 89 15:40:59 PST
Date: 6 Jan 89 15:40 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 14 Dec 88 01:00 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <890106-154059-1328@Xerox>
!
Forum: Cleanup
Issue: CLOSE-CONSTRUCTED-STREAM
References: Close (CLtL p. 332), WITH-OPEN-STREAM
(CLtL p 330), make-synonym-stream, make-broadcast-stream,
make-concatenated-stream, make-two-way-stream,
make-echo-stream, make-string-input-stream,
make-string-output-stream, with-input-from-string,
with-output-from-string
Related issues: CLOSED-STREAM-OPERATIONS
Category: Clarification/Change
Edit history: Masinter, 6-Jan-89, Version 1
Problem description:
First some terminology:
A "composite" stream is one created with make-synonym-stream,
make-broadcast-stream, make-concatenated-stream, make-two-way-stream,
make-echo-stream.
A "constructed" stream is either a composite stream or one created with
make-string-input-stream, make-string-output-stream,
with-input-from-string, with-output-from-string.
The function "CLOSE" is currently described in 21.3, which starts "This
section contains discussion of only those operations that are common to all
streams." This would seem to imply that they apply to constructed streams.
The definition of CLOSE "The argument must be a stream. No further
input/output operations may be performed on it. ... " It further states
"... and it is permissible to close an already closed stream."
However, the behavior on the constructed streams is not well defined, and
implementations (apparently) differ.
Proposal (CLOSE-CONSTRUCTED-STREAM:IS-ERROR):
It "is an error" to call CLOSE on a constructed stream. CLOSE might signal
an error, or the result of CLOSE could cause the constituent streams to be
closed, etc, but the effect is implementation-dependent.
Proposal: (CLOSE-CONSTRUCTED-STREAM:SIGNALS-ERROR)
Calling CLOSE on a constructed stream signals an error.
Proposal (CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY):
The effect of CLOSE on a constructed stream is to close the "argument"
stream only, but none of the constituents; that is,
a) no i/o operations are permitted after the call to CLOSE on the stream
given to CLOSE. In addition, for streams created with
make-string-output-stream, the result of get-output-stream-string is
unspecified. For other composite streams, the "links"
b) the call to CLOSE has no effect on other streams:
for broadcast, two-way, synonym or echo streams, none of
the constituent streams are closed (the "links"
to the constituents may be broken; if the proposal
in STREAM-ACCESS passes, the results of
the accessor functions there are unspecified after
the call to CLOSE.)
Examples:
tbd
Rationale:
Signalling an error is reasonable if no Common Lisp program ever needs to
call CLOSE on a composite stream. We could not come up with a legitimate
case where you wouldn't instead close the underlying stream if that's what
you wanted.
Allowing the result to be implementation dependent is the "status quo".
ARGUMENT-STREAM-ONLY is probably the "safest" in that it makes it harder to
accidentally close a stream that wasn't intended.
Current practice:
Envos Medley seems to implement ARGUMENT-STREAM-ONLY.
Cost to Implementors:
Varying, depending on the current level of conformance. Making the changes
themselves is probably trivial (to the "close" method for each kind of
constructed stream type)
Cost to Users:
Likely small; we've not found any good uses for CLOSE on composite streams.
Cost of non-adoption:
Continued minor ambiguity
Performance impact:
near zero
Benefits:
The language would be more well specified.
Esthetics:
Well-specified languages are usually easier to deal with.
Discussion:
We discussed, and there was some sentiment, for another alternative: CLOSE
closes the constituent streams as well. It could be an incompatible change
for some implementations. it makes more sense for things like broadcast
streams (which are usually non-interactive) than it does for echo streams
(which are sometimes interactive).
ARGUMENT-STREAM-ONLY is weird. i can't figure out what i think of it. it
seems counterintuitive and yet it probably wouldn't be harmful if it were
well-defined that this was what it did.
∂06-Jan-89 2258 CL-Cleanup-mailer Issue FUNCTION-COMPOSITION
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:58:14 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via INTERNET with SMTP id 256965; 7 Jan 89 01:56:21 EST
Date: Sat, 7 Jan 89 01:55 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue FUNCTION-COMPOSITION
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, cperdue@Sun.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890106185519.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890107065549.9.GSB@GANG-GANG.SCRC.Symbolics.COM>
Date: Fri, 6 Jan 89 18:55 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I can't support any abbreviated name, and CONSTANT-FUNCTION is too long.
ALWAYS is at least current practice in an existing dialect.
However, if you really can't deal, how about CONSTANTLY.
(MAPCAR (CONSTANTLY 7) '(A B C)) => (7 7 7)
yes to CONSTANTLY. ALWAYS is a bad choice.
∂06-Jan-89 2311 CL-Cleanup-mailer Ballots, please
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Jan 89 23:11:00 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate id AA08288g; Fri, 6 Jan 89 23:07:09 PST
Received: by bhopal id AA02680g; Fri, 6 Jan 89 23:09:24 PST
Date: Fri, 6 Jan 89 23:09:24 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901070709.AA02680@bhopal>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 00:23 PST <890106-002339-193@Xerox>
Subject: Ballots, please
Some of the senior staff at Lucid will meet early next week to discuss
what response to make to the ballot. We will continue, however, to
make our interests known on individual issues as the needs arise.
-- JonL --
∂06-Jan-89 2349 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 23:48:53 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 89 23:47:46 PST
Date: 6 Jan 89 23:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFPACKAGE (Version 7)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Wed, 14 Dec 88
01:42:24 PST
To: Jon L White <jonl@lucid.com>
cc: barmar@Think.COM, CL-CLEANUP@sail.stanford.edu
Message-ID: <890106-234746-2045@Xerox>
After re-reading the discussion, I think the only issue is to define
explicitly what "at variance with the current state of that package" means.
I think a subjunctive definition might be OK, here's a try:
Add to the Proposal:
A DEFPACKAGE is "at variance with the current state of a pre-existing
package" if the result of executing the DEFPACKAGE with a different name
would create a package with a different set of exported symbols, a
different set of USEd packages, with any *more* shadowing symbols, or a
different set of nicknames.
A DEFPACKAGE is not at variance with the current state of a pre-existing
package even if the size of the pre-existing package differs from the :SIZE
of the DEFPACKAGE form, or if it the pre-existing package has more internal
symbols.
If there is a new proposal (rather than an amendment), it might be useful
to add to the discussion:
"One of the most common recipes for disaster is to have differing EXPORTs
in two package definitions, and then to load a file which was compiled in
one of these two enviroments into a "runtime" image that has the other
environment. The file being loaded may expect to inherit some symbols
(due to their being EXPORT'd from a "used" package at compile time); but
failing to inherit at "run time", it will create a Doppelganger in the
current package
Virtually any difference *can* be made to be critical, due to the fact
that the package system is a global database in a flat namespace (there
is no "context" for FIND-PACKAGE). Leaving it undefined as to how to
handle varying package re-definitions allows the implementations to
experiment with helpful warnings, recovery stratagies, etc."
How this will get into the standard in the Rationale section is not clear,
but hopefully KC can find a way to cope with it.
∂07-Jan-89 0007 CL-Cleanup-mailer Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jan 89 00:07:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 JAN 89 00:03:16 PST
Date: 7 Jan 89 00:02 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE (Version 2)
To: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
Message-ID: <890107-000316-2049@Xerox>
I couldn't resist changing the name of the issue lest we have another
future issue also dealing with DEFSTRUCT-ACCESS-FUNCTIONS.
!
Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
References: DEFSTRUCT (p. 308)
Category: CHANGE
Edit history: 5-Oct-88, Version 1 by Chapman
6-Jan-89, Version 2 by Masinter
Problem Description:
It is left up to the implementation whether or not the DEFSTRUCT access
function is declared inline. Thus, some programmers write:
(PROCLAIM '(INLINE FOO-A FOO-B FOO-C))
(DEFSTRUCT FOO A B C)
in portable code in case the code is run in an implementation where
the INLINE proclaimation is meaningful but not the default for
DEFSTRUCT accessors.
Proposal (DEFSTRUCT-ACCESS-FUNCTIONS-INLINE:YES)
Make it mandatory that implementations declare access functions inline.
Of course the declaration may or may not mean anything within the
particular implementation.
Rationale:
This requirement resolves user ambiguity.
Current Practice:
We've not surveyed many implementations, but apparently they
differ as to whether INLINE for defstruct accessors is the default.
Cost to implementors:
Minimal.
Cost to users:
Minimal.
Benefits:
This clarification will give users insurance that the inline declaration
has been made for the access function.
Aesthetics:
Specified is simpler than not-specified.
Performance Impact:
Small. Some programs might have different size/space characteristics.
Discussion:
We know of no implementation where such automatic inlining would
be inappropriate, even in cases where INLINE is recognized. Certainly
implementations are free to ignore INLINE proclaimations even
selectively, i.e., ignore INLINE proclaimations only for DEFSTRUCT
accessors. The major impact of this proposal is just to make it clear
that a separate (PROCLAIM '(INLINE ...)) is not necessary.
∂07-Jan-89 0100 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jan 89 01:00:38 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate id AA08362g; Sat, 7 Jan 89 00:56:37 PST
Received: by bhopal id AA02979g; Sat, 7 Jan 89 00:58:52 PST
Date: Sat, 7 Jan 89 00:58:52 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901070858.AA02979@bhopal>
To: Cassels@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@Sail.Stanford.EDU, DySak@STONY-BROOK.SCRC.Symbolics.COM,
JGA@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: Robert A. Cassels's message of Fri, 6 Jan 89 17:36 EST <19890106223654.4.CASSELS@GROUSE.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 1)
I like this. It's about time [but probably too late for an X3J13
vote in January?].
-- JonL --
∂07-Jan-89 0927 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Jan 89 09:27:16 PST
Received: from JACKIE-O.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 159618; Sat 7-Jan-89 12:24:35 EST
Date: Sat, 7 Jan 89 12:24 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19890107051524.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890107172420.3.MLY@JACKIE-O.AI.MIT.EDU>
Date: Sat, 7 Jan 89 00:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
[...]
Since use of the compile-time environment for types should be quite rare,
this was seen as much less of a burden than modifying existing functions
to take new optional arguments.
Not so. Consider compiler optimisations of (MAKE-ARRAY # :ELEMENT-TYPE #)
When I last wrote a CL type system I needed a mess of parallel
COMPILER-SUBTYPEP and COMPILER-UPGRADE-ARRAY-ELEMEN-TYPE (and so forth)
functions. Using compilation-environment technology would have been far
preferable.
I give MAKE-ARRAY optimisation merely as an example -- I feel `user'
code has the same sorts of needs.
∂07-Jan-89 2109 CL-Cleanup-mailer votes at Hawaii
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jan 89 21:09:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 JAN 89 20:51:56 PST
Date: 7 Jan 89 20:50 PST
From: masinter.pa@Xerox.COM
Subject: votes at Hawaii
In-reply-to: Jon L White <jonl@lucid.com>'s message of Sat, 7 Jan 89
00:58:52 PST
To: Jon L White <jonl@lucid.com>
cc: CL-Cleanup@Sail.Stanford.EDU
Message-ID: <890107-205156-2877@Xerox>
If we bring enough copies and no-one invokes the "two-week" rule, we can
get issues passed at the Hawaii meeting.
∂07-Jan-89 2109 CL-Cleanup-mailer [alarson@src.honeywell.com (Aaron Larson): Ballots, please]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jan 89 21:09:33 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 07 JAN 89 21:06:55 PST
Date: 7 Jan 89 21:04 PST
From: masinter.pa@Xerox.COM
Subject: [alarson@src.honeywell.com (Aaron Larson): Ballots, please]
To: cl-cleanup@sail.stanford.edu
Message-ID: <890107-210655-2892@Xerox>
----- Begin Forwarded Messages -----
Return-Path: <alarson@src.honeywell.com>
Received: from moon.src.honeywell.com ([129.30.1.10]) by Xerox.COM ; 07 JAN
89 19:26:09 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM
by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88)
id AA17213; Sat, 7 Jan 89 21:25:49 CST
Posted-Date: Sat, 7 Jan 89 21:24:16 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA13383; Sat, 7 Jan 89 21:24:16 CST
Date: Sat, 7 Jan 89 21:24:16 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8901080324.AA13383@pavo.src.honeywell.com>
To: masinter.pa
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 00:23 PST
<890106-002339-193@Xerox>
Subject: Ballots, please
This bounced the first time so...
To: masinter.pa@xerox.COM
Subject: Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
The following is my ballot. There are a couple of baked comments, mostly
notes to myself that I've not had time to check out throughly. If they are
not clear or usefull, simply ignore them. All my comments appear on a
single line at the side of the issue name, if this is a mess on your
system, let me know and I'll reformat. Also, note that I did not copy
cl-cleanup.
!
ARGUMENTS-UNDERSPECIFIED:SPECIFY Yes.
Version 4, 21-Sep-88, Mailed 4 Dec 88
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING Yes.
Version 9, 31-Oct-88, Mailed 5 Dec 88
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY Yes
Version 5, 5-Dec-88, Mailed 5 Dec 88
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE Yes
Version 1, 14-Sep-88, Mailed 6 Oct 88
DECLARATION-SCOPE:NO-HOISTING Yes.
DECLARATION-SCOPE:LIMITED-HOISTING Prefer
no-hoisting, but if there was serious objection, would accept this one
also.
Version 4, 15-Nov-88, Mailed 9-Dec-88
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION Yes. (I
thought this already passed?)
Version 4, 5-Dec-88, Mailed 5-Dec-88
DECLARE-TYPE-FREE:ALLOW Yes.
Version 8, 7-Dec-88, Mailed 9-Dec-88
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE Abstain
Version 2, 30-Sep-88, Mailed 6 Oct 88
DEFPACKAGE:ADDITION Yes. I
believe that "should signal an error" should be "will signal an error".
Version 7, 2-Nov-88, Mailed 5 Dec 88
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY Yes
Version 2, 21-Sep-88, Mailed 6 Oct 88
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES Yes
Version 3, 7 Dec 88, Mailed 12-Dec-88
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR Confused,
why string= on the names. Does that mean that foo:a and bar:a cannot both
be slots in the same structure? (check where accessors are interned).
Version 4, 31-Oct-88, Mailed 12-Dec-88
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE Abstain
DESCRIBE-INTERACTIVE:NO Yes
Version 4, 15-Nov-88 , Mailed 7-Dec-88
DOTTED-MACRO-FORMS:ALLOW Yes
Version 3, 15-Nov-88, Mailed 7-Dec-88
EQUAL-STRUCTURE:STATUS-QUO Yes
Version 5, 1-Oct-88, Mailed 8 Oct 88
EXIT-EXTENT:MINIMAL No,
semantics are bad.
EXIT-EXTENT:MEDIUM Yes
Version 5, 12-Dec-88, Mailed 12-Dec-88
EXPT-RATIO:P.211 Yes
Version 3, 31-Oct-88, Mailed 7 Dec 88
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION No. fixnum
is defined to be non portable, if portable code needs to be written, then
(integer low up) is the way to specify it.
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM I agree
bignum is not usefull, but there are other non usefull aspects of the
language, and changing them now requires better justification.
Version 4, 7-Dec-88, Mailed 12-Dec-88 I don't
feel strongly about either of the above statements.
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN Yes
Version 2, 2 Oct 88, Mailed 6 Oct 88
FORMAT-PRETTY-PRINT:YES Yes
Version 7, 15 Dec 88, Mailed 7 Dec 88
FUNCTION-COMPOSITION:NEW-FUNCTIONS No. Also,
there is an error in the proposal, the example for find-if specifies AND
and DISJOIN to be equivalent. Not very "perspicuous".
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS No
Version 4, 12 Dec 88, Mailed 12 Dec 88
FUNCTION-DEFINITION:FUNCTION-SOURCE Abstain
Version 2, 09-Dec-88 , Mailed 9 Dec 88
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE Yes.
Version 3, 7-Dec-88, Mailed 12-Dec-88
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE No/Abstain
Version 5, 14-Nov-88 , Mailed 8-Dec-88
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD Yes
Version 2, 8 Dec 88, Mailed 8 Dec 88
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER Abstain
Version 7, 8-Dec-88, Mailed 9-Dec-88
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS ??, very
long. Check SXHASH, I thought it was supposed to work accross different
invocations of lisp. This appears to not be the case according to the
proposal. Since the proposal really i
sn't changing the language (I hope), then it is really only a clarification
of existing status, but I'm not sure I understand the issue any more now
than before I read it.
Version 1, 11-Nov-88 , Mailed 12 Dec 88
HASH-TABLE-TESTS:ADD-EQUALP Yes
Version 2, 8-Dec-88, Mailed 8 Dec 88
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY Yes,
conditionally on defpackage passing.
Version 4, 12-Dec-88, Mailed 12-Dec-88
LAMBDA-FORM:NEW-MACRO Abstain
Version 4, 22-Nov-88, Mailed 8-Dec-88
LCM-NO-ARGUMENTS:1 Yes
Version 1, 17 Oct 88, Mailed 8 Dec 88
LISP-SYMBOL-REDEFINITION:DISALLOW Yes
Version 5, 22-Nov-88, Mailed 8 Dec 88
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT yea sure.
People writing portable code have more subtle problems to worry about than
the default :USE list anyhow.
Version 2, 8 Oct 88, Mailed 12-Dec-88
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE Yes
Version 2, 09-Jun-88, Mailed 8 Oct 88
NTH-VALUE:ADD Abstain/No
Version 4, 8-Dec-88, Mailed 8 Dec 88
PACKAGE-CLUTTER:REDUCE yes.
Version 6, 12-Dec-88, Mailed 12-Dec-881
PACKAGE-DELETION:NEW-FUNCTION YES, (minor
editorial comment sent to cleanup (sorry bout that).
Version 5, 21 nov 88, Mailed 8 Dec 88
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN Yes
Version 1 27-Jun-88, Mailed 7 Oct 88
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR Yes
Version 3, 8-Oct-88, Mailed 8 Oct 88
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK Yes
Version 3, 20 Sep 88, Mailed 8 Oct 88
PROCLAIM-LEXICAL:LG If it can
be implemented easily then I'm for it. (I thought symbol-value got the
global value, not the dynamic one??)
Version 9, 8-Dec-88, Mailed 12-Dec-88
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER Yes
Version 3, 9-Oct-88, Mailed 14-Oct-88
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL Yes
Version 1, 14-Sep-88, Mailed 7 Oct 88
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE Yes.
Version 6, 9 Dec 88, mailed 09 Dec 88
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
REST-LIST-ALLOCATION:MAY-SHARE All three
stink. No idea what to do.
REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
RETURN-VALUES-UNSPECIFIED:SPECIFY Yes
Version 6, 9 Dec 88 mailed 9-Dec-88
ROOM-DEFAULT-ARGUMENT:NEW-VALUE Abstain
Version 1 12-Sep-88 mailed 8 Oct 88
[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS Much better
than before. Inroducing (setf name) as names for functions is still ugly.
Questions such as what about macros?? Generalized function specs? etc. I
would vote for it if nothing
better comes along.
Version 3, 4-Nov-87, mailed Nov 87
SETF-PLACES:ADD-SETF-FUNCTIONS No, it
would require most code to have things like (flet
((#.(underlying-spec-to-name ..))) (defsetf...)) which is very gross. It
would also be a very big portability issue, because implemen
tations with function specs would probably work without the defsetf, which
is fairly subtle.
Version 1, 11-Nov-88, mailed 9-Dec-88
SETF-SUB-METHODS:DELAYED-ACCESS-STORES Yes
Version 5, 12-Feb-88 mailed 8 Oct 88
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS Yes
Version 8, 8 Jul 88, Mailed 7 Oct 88
STEP-ENVIRONMENT:CURRENT Yes
Version 3, 20-Jun-88, mailed 7 Oct 88
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS Yes, order
of perferense stream-access:add-types-accessors, then
add-types-predicates-accessors, I'm not fond of add-predicates-accessors,
but not stronly opposed.
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS Yes, Prefer
ammendment. Also, I believe that the specification of the "basic
properties" makes no mention of the fact that NIL can be returned by any of
the functions. This somewhat implies
that they are required to return non nil values, although I believe the
proposal permits them too.
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
SUBTYPEP-TOO-VAGUE:CLARIFY Yes
Version 4, 7-Oct-88, mailed 7 Oct 88
SYMBOL-MACROLET-DECLARE:ALLOW Yes (check
-SEMANTICS)
Version 2, 9-Dec-88, mailed 9 Dec 88
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM Yes (need
to think about it more, complex issue)
Version 5, 30-Nov-88, mailed 9 Dec 88
TAGBODY-CONTENTS:FORBID-EXTENSION Yes
Version 5, 9-Dec-88 mailed 9 Dec 88
TAILP-NIL:T Yes
Version 5, 9-Dec-88, mailed 12-Dec-88
TEST-NOT-IF-NOT:FLUSH-ALL No/Abstain
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS Yes
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW Yes
Version 2, 2-Dec-88, mailed 12-Dec-88
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE No/Abstain.
Error checking gained by disallowing (var) is more important to me than
symmetry. If anything (var) should be disallowed in all forms.
Version 3, 08-Oct-88, mailed 9 Dec 88
----- End Forwarded Messages -----
∂07-Jan-89 2153 CL-Cleanup-mailer Issue PATHNAME-PRINT-READ, v1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jan 89 21:53:40 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate id AA08743g; Sat, 7 Jan 89 21:49:30 PST
Received: by bhopal id AA05537g; Sat, 7 Jan 89 21:51:44 PST
Date: Sat, 7 Jan 89 21:51:44 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901080551.AA05537@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: IIM@ECLA.USC.EDU, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 4 Jan 89 18:47 EST <890104184739.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue PATHNAME-PRINT-READ, v1
re: - I think #P is better than #. for the same reasons that Touretzky
proposed #H instead of relying on #. . That is, because most Lisp
data can be understood by engines considerably less complex than
Lisp itself. . . .
I don't think Touretzky was thinking along those lines when he made
the #H proposal. Perhaps you are remember pieces of the following
message, which was part of a lengthy discussion that took place on
the Common-Lisp mailing list last summer.
-- JonL --
Date: Fri, 24 Jun 88 16:56:00 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
To: cperdue@sun.com
Cc: ELIOT@cs.umass.edu, Moon@stony-brook.scrc.symbolics.com,
common-lisp@sail.stanford.edu
In-Reply-To: Cris Perdue's message of Fri, 17 Jun 88 10:16:38 PDT <8806171716.AA01554@clam.sun.com>
Subject: #.
re: > (I don't count #.(make-hash-table...) because it's so gross.)
. . .
I would like to add my agreement to David Moon's statement. With the
#. readmacro you don't have to learn extra syntax to understand the
printed representation, and it is nothing if not adequately general.
Let's just say that it is "nothing". The problem with #. is precisely that
it is not syntax; rather, it is an "out" where the designers of the language
failed to come up with a syntax. To see this more clearly, consider writing
a trivial C program to read in "simple" Lisp expressions into equivalent data
structures of the C world. Parsing is no real problem [maybe could even
be yacc'd away], INTERNing of symbols is just a table lookup, numbers is
numbers [hey, even C can do fixnums and floats!], defstructs can be structs,
strings are strings, and so on; cons cells etc. can be cut out of mallocated
space, and pointer-type variables make it easly to link things together.
But there is no reasonable equivalent for the #. requirements -- no matter
how trivial the data-type returned, it implies the existence of a Lisp
EVALuator just to parse-&-build the representation. That's a LOT to require
for merely constructing up some simple data structures.
Thus while #. could be viewed as an adequate escape mechanism, it certainly
couldn't be part of a general interchange language.
And yet the hard problems are not limited to the "interchange" cases.
Consider file-processors other than LOAD or COMPILE-FILE (such as the
cross-reference program described by Tom Gruber in the first issue of
Lisp Pointers). Such a processor will want to READ a file of Lisp code,
but not necessarily evaluate anything in it. How will it react to the
file [named, say "/u/loser/trojan-horse.lisp"]:
(defun gift-horse (x)
#.(progn (punch-paper-tape)
(delete-all-user-files)
(logout)
'x))
-- JonL --
∂07-Jan-89 2212 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jan 89 22:12:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 07 JAN 89 22:04:43 PST
Date: 7 Jan 89 22:04 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
In-reply-to: your message of 12 Dec 88 16:00 PST
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890107-220443-2934@Xerox>
On p. 317, CLtL gives an example
(defstruct (binop (:type list))
(operator '? :type symbol)
operand-1
operand-2)
and says in the running text ...
"... and TYPE-OF will return LIST when given a BINOP structure."
I guess if the example survives in the standard it should be fixed.... I
don't see a compelling reason why
(TYPE-OF '(A B C)) should be LIST instead of CONS, do you?
∂07-Jan-89 2223 CL-Cleanup-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jan 89 22:23:24 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate id AA08764g; Sat, 7 Jan 89 22:18:57 PST
Received: by bhopal id AA05601g; Sat, 7 Jan 89 22:21:13 PST
Date: Sat, 7 Jan 89 22:21:13 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901080621.AA05601@bhopal>
To: masinter.pa@Xerox.COM
Cc: Gray@DSG.csc.ti.com, KMP@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 14:02 PST <890106-140422-1103@Xerox>
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
re: I fail to see the necessity of correlating the behavior of backquote with
the behavior of APPEND, since we've not ever specified that backquote ...
See CLtL, pages 350-51.
-- JonL --
∂07-Jan-89 2235 CL-Cleanup-mailer Issue: DEFSTRUCT-REDEFINITION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jan 89 22:34:58 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 JAN 89 22:30:18 PST
Date: 7 Jan 89 22:29 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFSTRUCT-REDEFINITION (Version 2)
Message-ID: <890107-223018-2952@Xerox>
I've not known exactly what to do with this issue even though I said I
would tackle it. This proposal a fairly arbitrary choice of the options we
could consider, but it is most consistent with my experience of trying to
make DEFSTRUCT efficient.
!
Status; **DRAFT**
Issue: DEFSTRUCT-REDEFINITION
References: DEFSTRUCT (CLtL pp 305-320)
Related-issues: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Category: CLARIFICATION
Edit history: Version 1 by Skona Brittain 07/26/88
Version 2 by Larry Masinter 7-Jan-89
Problem Description:
The case of a structure type being redefined is not discussed in CLtL. Is
it legal to redefine a DEFSTRUCT? What happens to DEFSTRUCTS that :INCLUDE
the one defined. What things might be "wired in" in compiled code that
refered to the previous DEFSTRUCT?
Proposal: (DEFSTRUCT-REDEFINITION:ERROR):
Redefining a DEFSTRUCT structure is not portable. The results of doing so
are not specified in the standard.
Rationale:
DEFSTRUCT is intended as "the most efficient" structure class. DEFCLASS
allows much more flexible structures to be defined. Thus, implementations
should be free to "wire in" much of the behavior of a DEFSTRUCT into
compiled code.
The issue of redefinition should be addressed since there are always
consequences that affect use of the structures.
Current Practice:
None of KCL, Lucid, & Symbolics detect a redefinition.
Envos Medley goes to some effort to detect if a new structure is
"compatible" with the old -- e.g., slots might change names, initial
values, but, since the space allocated in an instance is determined by the
:TYPE, an incompatible set of :TYPE forms would cause old instances to be
marked "obsolete". (The TYPE-OF an old instance changes to **OBSOLETE**,
for example.)
Cost to Implementors:
This proposal attempts to be consistent with current practice.
Cost to Users:
It is doubtful that any current programs actually define structures more
than once. Thus, constraints on DEFSTRUCT redefinition primarily affect the
debugging environment.
Cost of Non-Adoption:
Confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior should be
explicitly considered an error.
Discussion:
Common implementation techniques may cause the following behavior if a
DEFSTRUCT is redefined:
If the new DEFSTRUCT is identical to the old DEFSTRUCT except for the
initialization forms for slots, previous structure objects probably can
continue to be accessed with previously compiled slot accessors. DEFSTRUCT
constructor, test functions are proclaimed INLINE, and if these have
changed, previously compiled occurrences of them may behave unpredictably.
If any change is made to the definiton of the slots (either in number,
name, or :TYPE), attempting to execute a slot accessor of the old
definition may behave unpredictably: if a slot name of the old definition
also names a slot of the new definition, any "compiled" code might use the
old definition instead.
DEFSTRUCT constructor, test functions may also be proclaimed INLINE, and
may behave unpredictably if previously compiled. In particular, a compiled
occurance of a constructor might have the previously slot initial values
"wired in".
If the new DEFSTRUCT differs from the old in any aspect other than the
initialization forms for slots, the results of attempting to access any old
instance might result in unspecified behavior. For example, if the size of
the structure became considerably shorter, an old accessor might "access
off the end" of an instance of a new object; it might signal an error or
have other unpredictable results.
Masinter supports this proposal. If users want more flexibility than
DEFSTRUCT allows, they should use DEFCLASS.
Some felt strongly that just saying it's an error to redefine a structure
but not requiring the error to be signalled will cause users to be confused
by the differing seemingly erratic behavior and code.
Programming environments are allowed, encouraged, etc. to allow such
redefinition, perhaps with warning messages. It is beyond the scope of the
language standard to define those interactions, except to note that they
are not portable.
Here's an example where reexecuting an EQUAL DEFSTRUCT might result in
different behavior:
(defvar *token-counter* 0)
(defstruct token (cookie '("unique-string")) (counter (incf
*token-counter*)))
(defvar *first-token* (make-token))
(eql (token-cookie *first-token*) (token-cookie (make-token))) => true
(defstruct token (cookie '("unique-string")) (counter (incf
*token-counter*)))
(eql (token-cookie *first-token*) (token-cookie (make-token))) => false
I.e., even though the second DEFSTRUCT is EQUAL to the first, the
structures are not EQL.
This is related to the compiler issue QUOTE-MAY-COPY, but is not the same
issue, since that proposal isn't proposing that QUOTE might copy its value
*every time* it is executed.
∂08-Jan-89 0035 CL-Cleanup-mailer Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 00:35:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 00:31:43 PST
Date: 8 Jan 89 00:31 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Sat, 7 Jan 89
22:21:13 PST
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, Gray@DSG.csc.ti.com,
KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890108-003143-3022@Xerox>
I must have missed a tense there somewhere.
Let me try to say it a different way:
The meta-rules for backquote were derived "after the fact" as a way to
explain what backquote did; the use of APPEND and the equivalences there
were based on the old semantics of APPEND. Now that we've extended APPEND,
we have to change the meta-rules of backquote, but not the way that
backquote really works in most implementations.
I think the simplest way to "fix" the proposal is to change the second
meta-rule about nil to be
`(x1 x2 x3 ... xn . nil) may be interpreted to mean
(append [x1] [x2] [x3] ... [xn])
-- rather than reducing it to a previous case.
This implies that `(x1 x2 ... . ,form) as in the third meta-rule has the
same interpretation as `(x1 x2 ... ,@form).
This requires fixing the example, so that
`((,a b) ,c ,@d)
will be interpreted as
(append (list (append (list a) (list 'b))) (list c) d)
As far as I can tell, this is consistent with the way that Lucid Common
Lisp's backquote works anyway.
To: '((,a b) ,c ,@d)
Lucid 3.0 says:
(bq-list* (bq-cons a '(b)) c d)
ibuki 01/01 says
(list* (list a 'b) c d)
Franz says:
(list* (cons a '(b)) c d)
Medley says:
(il:bquote (((il:\\\, a) b) (il:\\\, c) (il:\\\,@d)))
which macroexpand to
(LIST* (CONS A (QUOTE (B))) C D)
Somebody borrowed my Mac so I can't try Coral or Procyon, and none of the
local Symbolics machines will let me remote login; but it looks like
*nobody* really tries to APPEND the last structure ever, anyway.
∂08-Jan-89 0113 CL-Cleanup-mailer Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 01:13:41 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 01:07:13 PST
Date: 8 Jan 89 01:06 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)
Message-ID: <890108-010713-3036@Xerox>
I shouldn't work on these things late at night....
The discussion from Kim Barrett mentioned "supplied-p" arguments.
I tried to think of uses of supplied-p arguments, and I thought
they were most useful in helping with some of the other
initialization variables. So must supplied-p arguments name
slots? If not, are arguments allowed which don't name slots
but are only used in the computation of &AUX or other
&OPTIONAL or &KEY defaults? I'm guessing so and propose
this amendment which enhances the proposal.
Let me know if you think this is a bad idea.
!
Forum: Cleanup
Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
References: CLtL page 316
Category: CHANGE
Edit history: 20-Sep-88, Version 1, Peck
21-Sep-88, Version 2, Masinter, minor revisions
8-Jan-89, Version 3, Masinter
Problem description:
Currently, DEFSTRUCT constructor functions can be either the default
constructor function, with *only* keyword arguments, or it can be a
so-called "By Order of Arguments" constructor function with explicitly
*no* keyword arguments. Other functions in Common Lisp allow a free
mix of required, optional, and keyword arguments.
With the current restriction, it is necessary to hand code a function that
will accept optional and keyword arguments and parse the supplied-p
variables explicitly. Even so, it is not obvious to the casual programmer
how to provide the same semantics as defstruct does with respect to default
values and the defstruct init-forms.
Proposal: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Allow &KEY keyword arguments in constructor forms of DEFSTRUCTs
and the &ALLOW-OTHER-KEYS token in addition to the &OPTIONAL,
&REST and &AUX arguments already allowed. Keyword arguments default
in a manner similar to that of &OPTIONAL arguments: if no default
is supplied in the lambda-list then the slot initform is used;
otherwise the slot is not initialized -- its initial value is
undefined.
If keyword arguments of the form ((key var) [default [svar]])
are specified, the "slot name" is matched with VAR (and not KEY).
Additional arguments that do not correspond to slot names but
are merely present to supply values used in subsequent initialization
computations are allowed.
Examples:
It should be possible to write forms like this:
(defstruct (foo (:constructor CREATE-FOO (a &optional b (c 'sea)
&key (d 2)
&aux e (f 'eff))))
(a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
(create-foo 10) => #S(foo a 10 b 2 c sea d 2 e nil f eff)
(create-foo 10 'bee 'see :d 'dee) => #S(foo a 10 b bee c see d dee e nil f eff)
In the definition:
(defstruct (frob (:constructor create-frob
(a &key (b 3 have-b) (c-token 'c)
(c (list c-token (if have-b 7 2))))))
a b c)
the c-token argument is used merely to supply a value used in the
initialization of the c slot. The "supplied-p" arguments of
keyword arguments might be of this form.
Rationale:
This is a logical extension of the specification which makes some
programming easier.
Current practice:
Many implementations signal an error if given &KEY arguments or
arguments that are not slot names. The latest version of IIM Common
Lisp allows &KEY arguments in this manner. Envos Medley
(Xerox Common Lisp) implements the proposal.
Cost to Implementors:
The modifications to allow intermixed keywords and optionals in implementations
that don't already are likely simple.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
The current situation is non-intuitive and needless restrictive.
Benefits:
Much easier for users to write the constructor function they want.
Probably implementation code would be reduced, since this would no
longer be an error.
Esthetics:
Minor improvement since it removes a needless restriction.
Discussion:
Possibly references to "By-position", "positional", and "By Order of
Arguments" constructor function might need to be changed to something else in
the standard. (They can still be called BOA-constructors, though, right? :-)
Version 2 of this proposal was on the January 1989 ballot.
∂08-Jan-89 0145 CL-Cleanup-mailer Re: Issue: DYNAMIC-EXTENT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 01:45:38 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 01:37:33 PST
Date: 8 Jan 89 01:36 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DYNAMIC-EXTENT (Version 2)
In-reply-to: Eric Benson <eb@lucid.com>'s message of Tue, 3 Jan 89 08:31:34
pst
To: Eric Benson <eb@lucid.com>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890108-013733-3047@Xerox>
I like this too.
If we can have a new version of this, I think it will subsume
REST-ARGUMENT-EXTENT, WITH-DYNAMIC-EXTENT and STACK-LET.
I think all that's necessary is to insert David's words in a proposal. I'd
do it now but I'm falling asleep.
∂08-Jan-89 0831 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jan 89 08:31:18 PST
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 517299; Sun 8-Jan-89 11:30:01 EST
Date: Sun, 8 Jan 89 11:29 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 2)
To: CL-Cleanup@Sail.Stanford.EDU
cc: DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
Supersedes: <19890106223654.4.CASSELS@GROUSE.SCRC.Symbolics.COM>
Message-ID: <19890108162936.5.CASSELS@GROUSE.SCRC.Symbolics.COM>
Issue: REAL-NUMBER-TYPE
Forum: CLEANUP
References: Table 4-1.
Category: ADDITION
Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
and John Aspinall
08-JAN-89, Version 2 by Bob Cassels -- incorporate
Masinter's suggestion and make REAL a CLOS class
Status: For Internal Discussion
Problem Description:
There is no standard type specifier symbol for the CL type
'(OR RATIONAL FLOAT).
Proposal (REAL-NUMBER-TYPE:REAL):
Add a standard type specifier
(REAL low high)
which means
(OR (RATIONAL low high) (FLOAT low high))
As with other such type specifiers, define that if the low and high
are omitted, the atomic specifier REAL may be used.
Clarify that NUMBER is equivalent to (OR REAL COMPLEX).
Make REAL a built-in CLOS class.
Proposal (REAL-NUMBER-TYPE:REALP):
Add a specific data type predicate REALP which tests for membership in
this type. [By analogy with NUMBERP.]
Test Case:
If a programmer wishes to test for "a number between 1 and 10", the
only current CL types would be '(or (rational 1 10) (float 1 10)) or
something like '(and numberp (not complexp) (satisfies range-1-10))
with (defun range-1-10 (real) (<= 1 real 10)). Both of these are
likely less efficient, and certainly less expressive than '(real 1 10).
Rationale:
Mathematics has a name for (OR RATIONAL FLOAT) -- it is "real".
This class is important because it is all the numbers which can be
ordered.
Throughout the "Numbers" chapter, the phrase "non-complex number" is
used.
MAX, MIN, p. 198 "The arguments may be any non-complex numbers."
CIS p. 207 "The argument ... may be any non-complex number."
Current Practice:
Probably nobody does this.
Cost to Implementors:
Some work is necessary to add this name. But since the underlying
type already exists the amount of work should be minimal.
Cost to Users:
Since this is an upward-compatible extension, it may be ignored by
users.
Cost of Non-Adoption:
Occasional inconvenience and/or inefficiency.
Benefits:
Mathematical clarity.
Ability to do CLOS method dispatch on the type.
Aesthetics:
As mentioned under "rationale," this would be a more concise way to
express a common programming idiom.
Discussion:
The name "non-complex number" is incorrect because future
implementations may wish to include numerical types which are neither
complex nor real. [e.g. pure imaginary numbers or quaternions]
The name "scalar" is incorrect because the mathematical concept of
scalar may indeed include complex numbers.
Fortran and Pascal use the name "real" to mean what CL calls
SINGLE-FLOAT. That should cause no significant problem, since a Lisp
program written using the type REAL will do mathematically what the
equivalent Fortran program would do. This is because Fortran's "real"
data-type is a subtype of the CL REAL type. The only differences
might be that the Lisp program could be less efficient and/or more
accurate.
A survey of several Fortran and Pascal books shows that the distinction
between INTEGER and REAL is that REAL numbers may have fractional
parts, while INTEGERs do not. Later discussions explain that REALs
cover a greater range. Much later discussions cover precision
considerations, over/underflow, etc. So the average Fortran or Pascal
programmer should be completely comfortable with the proposed Lisp
concept of REAL.
∂08-Jan-89 1327 CL-Editorial-mailer conformance & extensions issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 13:27:32 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 13:26:07 PST
Date: 8 Jan 89 13:25 PST
From: masinter.pa@Xerox.COM
Subject: conformance & extensions issues
To: cl-editorial@sail.stanford.edu, cl-cleanup@sail.stanford.edu
reply-to: cl-editorial@sail.stanford.edu
Message-ID: <890108-132607-3283@Xerox>
These was in discussion on the common lisp mailing list, but it is relevant
to the conformance discussion, and probably should be split up into
separate issues. I've not the time to do so myself. There's some overlap
with a couple of cleanup issues but not much. I think these are not so much
"cleanup" issues since they have to deal with the broad policies of
conformance and extension rather than individual functions/variables, so
I'd think they should be discussed in the "editorial" forum rather than
cleanup -- unless there is strong objection.
Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
Problem:
Is it OK to define Common Lisp functions with extra optional or keyword
parameters, with system dependent meanings?
Proposal: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS:NO-EXCEPT-AS-ALLOWED
No, except as explicitly allowed in the standard. Functions that may be
extended to take implementation-specific optional arguments are indicated
by an &REST IGNORE in their argument list. Functions that may be extended
to take additional keyword parameters are indicated by &ALLOW-OTHER-KEYS.
It isn't required that implementations signal errors at all safety/speed
setting, but this is not legitimate/conformal behavior.
Rationale:
The goal is not to outlaw any current extensions currently offered by
implementors, but to make the range of extensions to functions defined in
the standard well documented in the standard. Implementations that want to
extend functions that aren't explicitly allowed to be extended can instead
shadow them.
Issue: EXTRA-SYNTAX
Problem: is it OK to extend Common Lisp macros and special forms to take
additional syntax not specified?
Proposal: EXTRA-SYNTAX:NO
It isn't allowed.
Issue: EXTRA-RETURN-VALUES
Problem: Is it OK to return extra values from Common Lisp functions?
Proposal: No, except where explicitly allowed. The reason is that
additional arguments are visible to otherwise portable programs. "For
instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
will try to pass the wrong number of arguments to CONS if FLOOR returns an
extra value."
Issue: UNPSECIFIED-DATATYPES
Problem: Is it OK to define the behavior of functions on datatypes not
explicitly permitted in CLtL?
Proposal: UNPSECIFIED-DATATYPES:NO-EXCEPT-AS-EXPLICITLY-ALLOWED
Example: It is currently not allowed for an implementation to define + as
operating on vectors.
Rationale: While the original intent of CL designers ws that
implementations be permitted to do these things, they get in the way of
portability when they're done, since it is nearly impossible to detect when
a program has used one of these features. It is simple to define a new
function
acme-common-lisp:+ which has the behavior of the "portable" + plus all the
new whizzy features, too.
Issue: UNSOLICITED-MESSAGES
Problem: Is it legal for an implementation to produce unsolicited output,
e.g., GC notifications, autoload heralds, and progress messages from
COMPILE-FILE or LOAD?
Proposal: UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS
Unsolicited messages, such as GC notifications and autoload heralds, if
they are produced by an implementation, should not be directed to
*standard-output*, *error-output*. If an implementation produces them, they
may be produced on a stream that is not "shared" with any of the streams
that a user might redefine or redirect. (This really means that it is OK to
direct such notifications to *terminal-io* since a user may not redirect
*terminal-io*.)
Messages such as progress reports from LOAD and COMPILE are "solicited",
and are not covered by this issue. See issue COMPILE-AND-LOAD-VERBOSE.
Issue: MACRO-AS-FUNCTION
Problem: May implementations implement things documented as "macros" or
special forms be implemented as a function instead? PROG1 is the main
example, but there might be others.
Proposal: MACRO-AS-FUNCTION:YES
Things that are defined in CL as "macros" may have function definitions
instead if the semantics can be preserved. This is rare, perhaps only
restricted to
(defun prog1 (value &rest ignore) value)
(defun prog2 (value1 value2 &rest ignore) value2)
Rationale:
There are few cases, and there doesn't seem to be a good reason to disallow
it. It doesn't seem to interfere with portability.
∂08-Jan-89 1341 CL-Cleanup-mailer Issue: ELIMINATE-FORCED-CONSING (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 13:41:09 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 13:37:33 PST
Date: 8 Jan 89 13:36 PST
From: masinter.pa@Xerox.COM
Subject: Issue: ELIMINATE-FORCED-CONSING (Version 3)
To: cl-cleanup@sail.stanford.edu
Message-ID: <890108-133733-3295@Xerox>
I have not heard back from Joe Ginder on this issue. Does anyone else want
to pursue this? Otherwise it will be dropped. (I personally would just as
well see it dropped at this time.)
----- Begin Forwarded Messages -----
Date: 12 Dec 88 10:08 PST
From: masinter.pa
Subject: Re: discussion of Moon's comments re: ELIMINATE-FORCED-CONSING
In-reply-to: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Tue, 6 Sep
88 15:38:22 PDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu
Joe:
On 6 Sept 88 you said, in response to a critique from Moon. "I'll submit a
modified proposal for discussion."
There were some subsequent comments on the cl-cleanup mailing list, and
we've not heard back from you. The January 1989 meeting is fast
approaching; we don't have a new writeup on this issue to mail out in
advance; if we don't hear from you, we will not have a new version to bring
there either.
Please reply if you get this note (to cl-cleanup@sail.stanford.edu), about
your plans with respect to this issue.
----- End Forwarded Messages -----
∂08-Jan-89 1400 CL-Cleanup-mailer Re: Ballot
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 13:59:53 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA28981; Sun, 8 Jan 89 14:01:41 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA05226; Sun, 8 Jan 89 13:58:21 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA11196; Sun, 8 Jan 89 13:59:27 PST
Date: Sun, 8 Jan 89 13:59:27 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901082159.AA11196@clam.sun.com>
To: masinter.pa@Xerox.COM
Subject: Re: Ballot
Cc: cl-cleanup@sail.stanford.edu
> The ballot incorrectly listed only one of three alternatives:
>
> STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
> STREAM-ACCESS:ADD-TYPES-ACCESSORS
> STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
>
> Do you prefer the marked
>
> Y | STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
After reading the proposal again, I favor all of the proposals.
I will guess that the types are not useful for performance purposes,
and based on this, I prefer STREAM-ACCESS:ADD-PREDICATES-ACCESSORS,
but do not really oppose any of the proposals. I somewhat favor
having predicates even when the types exist, because the predicates
are usable with FUNCALL, APPLY, etc..
∂08-Jan-89 1405 CL-Cleanup-mailer Re: Ballot
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 14:05:22 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA29037; Sun, 8 Jan 89 14:07:13 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA05255; Sun, 8 Jan 89 14:03:54 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA11210; Sun, 8 Jan 89 14:04:58 PST
Date: Sun, 8 Jan 89 14:04:58 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901082204.AA11210@clam.sun.com>
To: cl-cleanup@sail.stanford.edu
Subject: Re: Ballot
I voted conditionally in favor of STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS.
I wish to add another comment to my vote in favor. This is a relatively
complex proposal, and I expect that some changes in details will
turn out to be desirable after there is experience with implementations.
X3J13 should expect to revisit this issue later to perfect the specification.
∂08-Jan-89 1416 CL-Cleanup-mailer Re: Issue: LISP-SYMBOL-REDEFINITION (Version 5)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 14:16:09 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA29125; Sun, 8 Jan 89 14:17:57 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA05290; Sun, 8 Jan 89 14:14:36 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA11223; Sun, 8 Jan 89 14:15:42 PST
Date: Sun, 8 Jan 89 14:15:42 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901082215.AA11223@clam.sun.com>
To: masinter.pa@Xerox.COM
Subject: Re: Issue: LISP-SYMBOL-REDEFINITION (Version 5)
Cc: cl-cleanup@sail.stanford.edu
> On your ballot, Sun commented "This appears to disallow too much."
>
> What things would you allow that are disallowed by this proposal?
Well, that *is* a fair question.
At minimum, it seems excessive to disallow application of TRACE
to functions in the LISP package. I have worked on implementations
of TRACE, and I believe it can work on functions in the Lisp package.
If we don't wish to support TRACE on all functions in the Lisp package,
we could require TRACE to either work or to not establish tracing
of the function.
I'd prefer to permit redefinition of macros and functions in the
LISP package, though I know there are difficulties. One would have
to admit that the compiler may treat any or all of these as inline,
assuming the built-in definitions, regardless of any user's redefinition.
Implementations must also be permitted to call any function in the LISP
package from any code whatsoever in the implementation. Perhaps this
makes redefinition unsupportable.
∂08-Jan-89 1735 CL-Cleanup-mailer Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jan 89 17:35:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 517316; Sun 8-Jan-89 15:28:30 EST
Date: Sun, 8 Jan 89 15:28 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
To: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19890107172420.3.MLY@JACKIE-O.AI.MIT.EDU>
Message-ID: <19890108202804.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 7 Jan 89 12:24 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Date: Sat, 7 Jan 89 00:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
[...]
Since use of the compile-time environment for types should be quite rare,
this was seen as much less of a burden than modifying existing functions
to take new optional arguments.
Not so. Consider compiler optimisations of (MAKE-ARRAY # :ELEMENT-TYPE #)
When I last wrote a CL type system I needed a mess of parallel
COMPILER-SUBTYPEP and COMPILER-UPGRADE-ARRAY-ELEMEN-TYPE (and so forth)
functions. Using compilation-environment technology would have been far
preferable.
I give MAKE-ARRAY optimisation merely as an example -- I feel `user'
code has the same sorts of needs.
Hmm, you're probably right.
∂08-Jan-89 1833 CL-Cleanup-mailer Issue: APPLYHOOK-ENVIRONMENT (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Jan 89 18:33:44 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00178g; Sun, 8 Jan 89 18:29:43 PST
Received: by blacksox id AA00920g; Sun, 8 Jan 89 18:31:55 pst
Date: Sun, 8 Jan 89 18:31:55 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901090231.AA00920@blacksox>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 11:49 PST <890106-115058-253@Xerox>
Subject: Issue: APPLYHOOK-ENVIRONMENT (Version 1)
This applies also to functions bound to *APPLYHOOK*, i.e., under the
description of *APPLYHOOK* on p.322, the following
"The non-NIL value of *APPLYHOOK* should be a function that takes
three arguments, a function, a list of arguments and an
environment..."
should be changed to say
"The non-NIL value of *APPLYHOOK* should be a function that takes
two arguments, a function and a list of arguments..."
∂08-Jan-89 2251 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 22:51:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 22:48:45 PST
Date: 8 Jan 89 22:47 PST
From: masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, jonl@lucid.com, IIM@ECLA.USC.EDU
line-fold: NO
Subject: Issue: EXIT-EXTENT (Version 6)
cc: masinter.pa@Xerox.COM
Message-ID: <890108-224845-3526@Xerox>
I'm hoping we can get this one voted on, at least to the
intent. It is probably true that an exact definition of
what we mean will be difficult to express without a formal
semantics, but I think it is clear that -- by now -- we
actually know what the proposals are trying to say, even
when more precision would be welcome.
I've tried to shorten the issue writeup by removing some
of the discussion of cases for which the semantics was not
ambiguous while still defining terms.
I am sick of this issue, even with only 331K bytes of
mail on it.
!
Issue: EXIT-EXTENT
References: CATCH, THROW (p 142),
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Related issues: UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: ... Version 5 of UNWIND-PROTECT-NON-LOCAL-EXIT, 23-May-88 ...
Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter, minor edits
Version 3, 7-Oct-88, by Moon, wording improvements
Version 4, 7-Dec-88, by Masinter, add MEDIUM from
UNWIND-PROTECT-NON-LOCAL-EXIT, discussion.
Version 5, 12-Dec-88, Masinter, clarify MINIMAL allows MEDIUM
Version 6, 8-Jan-89, Masinter, fix some bugs
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
For example, at what point is it no longer possible to RETURN-FROM
a particular BLOCK?
An "exit" refers to a point from which control can be transferred.
For a THROW or RETURN-FROM, the "exit" is the corresponding CATCH
or BLOCK body. For a GO, the "exit" is the form within the TAGBODY
which was being executed at the time the GO is performed.
The extent of an exit is dynamic; it is not indefinite. The extent
of an exit begins when the corresponding form (CATCH, BLOCK or TAGBODY
clause) is entered. When the extent of an exit has ended, it is no
longer legal to return from it.
The extent of an exit is not the same thing as the scope of the
designator by which the exit is identified. For example, a BLOCK
name has lexical scope but the extent of its exit is dynamic; the
scope of a CATCH tag could differ from the extent of the CATCH's
return point. (That's part of what is at issue here.)
The ambiguity at issue arises for the case where there are transfers
of control from the cleanup clauses of an UNWIND-PROTECT.
When a transfer of control is initiated by GO, RETURN-FROM or THROW,
a variety of events occur before the transfer of control is complete.
In particular,
(a) the cleanup clauses of any intervening UNWIND-PROTECT clauses
are evaluated,
(b) intervening dynamic bindings of special variables and catch tags
are undone,
(c) intervening exits are "abandoned", i.e., their extent ends and it
is no longer legal to attempt to transfer control through them,
(d) the extent of the exit being invoked ends,
(e) control is finally passed to the target.
The order of these events is not explicit in CLtL, however. The
implementation note on p.142 gives a clue about the interweaving
of (a) and (b), but there are differing opinions about the times
at which (c) and (d) may occur. In particular,
Is it legal for an implementation to end the extent of all
intervening exits before processing the cleanup clauses of intervening
UNWIND-PROTECTs?
What is the dynamic context at the time UNWIND-PROTECT clauses are
evaluated: how is the unwinding of dynamic bindings intertwined with
evaluation of UNWIND-PROTECT cleanup clauses?
Proposal (EXIT-EXTENT:MINIMAL):
The extent of an exit--whether it is being "abandoned" because it is
being passed over, or it is itself the target exit--ends as soon as
the transfer of control is initiated. That is, the events (c) and (d)
at the beginning of the initiation of the transfer of control. In the
language of the implementation note on p.142, the extent ends at the
beginning of the second pass. It is an error to attempt a transfer
of control to an exit whose dynamic extent has ended.
Otherwise, events (a) and (b)--the undoing of dynamic binding of special
variables and CATCH tags, and the execution of UNWIND-PROTECT cleanup
clauses--are performed in the order corresponding to the reverse order
in which they were established, as implied by the implementation note
on p.142. The effect of this is that the cleanup clauses of an UNWIND-PROTECT
will see the same dynamic bindings of variables and CATCH tags as were
visible when the UNWIND-PROTECT was entered.
This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL. A program that presumed a longer extent
would be in error. Implementations may support longer extents for
exits than is required by this proposal; in particular, an
implementation which allowed the larger extent of the MEDIUM
proposal below would still conform.
Proposal (EXIT-EXTENT:MEDIUM):
The events of (a), (b), (c) and (d) are interwoven in the reverse
order in which they were established. In particular, the extent of
a passed-over exit ends when control reaches a frame that was
established before the exit was established.
In particular, it is legal, during the evaluation of an UNWIND-PROTECT
cleanup form executed because of a non-local transfer of control, to
initiate a new transfer of control to an exit intervening between the
UNWIND-PROTECT and the original target; the original processing of
transfer of control is abandoned.
Examples:
;; Error under either proposal: BLOCK exits normally before RETURN
(funcall (block nil #'(lambda () (return))))
;; Error under either proposal: normal exit before GO
(let ((a nil))
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
;; Error under either proposal: TAGBODY is passed over, before GO
(funcall (block nil
(tagbody a (return #'(lambda () (go a))))))
;;returns 2 under MEDIUM, is error under MINIMAL
(block nil
(unwind-protect (return 1)
(return 2)))
;;returns 2 under MEDIUM, is error under MINIMAL
(block a
(block b
(unwind-protect (return-from a 1)
(return-from b 2))))
;; returns 2 under MEDIUM, is error under MINIMAL
(catch nil
(unwind-protect (throw nil 1)
(throw nil 2)))
;; returns 2 under MEDIUM, is error under MINIMAL
;; because the catch of B is passed over by
;; the first THROW, hence portable programs must assume its dynamic extent
;; is terminated. The binding of the catch tag is not yet disestablished
;; and therefore it is the target of the second throw.
(catch 'a
(catch 'b
(unwind-protect (throw 'a 1)
(throw 'b 2))))
;; the following is an error under MINIMAL; the extent of the
;; inner catch terminates as soon as the THROW commences, even
;; though it remains in scope. Thus, the THROW of :SECOND-THROW
;; sees the inner CATCH, but its extent has ended.
;; under MEDIUM, it prints "The inner catch returns :SECOND-THROW"
;; and then returns :OUTER-CATCH.
(catch 'foo
(format t "The inner catch returns ~s.~%"
(catch 'foo
(unwind-protect (throw 'foo :first-throw)
(throw 'foo :second-throw))))
:outer-catch))
;; Following returns 10 under either proposal. The inner
;; CATCH of A is passed over, but because that CATCH
;; is disestablished before the THROW to A is executed,
;; it isn't seen.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
;; Following is an error under MINIMAL because the extent of
;; the (CATCH 'FOO ...) exit ends when the (THROW 'FOO ...)
;; commences.
;; Under MEDIUM, the pending exit to tag FOO is discarded by the
;; second THROW to BAR and the value 4 is transferred to
;; (CATCH 'BAR ...), which returns 4. The (CATCH 'FOO ...)
;; then returns the 4 because its first argument has returned
;; normally. XXX is not printed.
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
;; Following returns 4 under either proposal; XXX is not printed.
;; The (THROW 'FOO ...) has no effect on the scope of the BAR
;; catch tag or the extent of the (CATCH 'BAR ...) exit.
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
;;The following are legal and print 5 under either proposal:
(block nil
(let ((x 5))
(declare (special x))
(unwind-protect (return)
(print x))))
(block nil
(let ((x 5))
(declare (special x))
(unwind-protect
(if (test) (return))
(print x))))
Rationale:
For MINIMAL: Giving exits the smallest extent consistent with CLtL
maximizes freedom for implementations; there are few applications,
if any, that require a longer extent.
For MEDIUM: Giving exits a longer extent has cleaner semantics.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target BLOCK or CATCH at the moment the values are returned, and
end the extent of a passed-over exit at the moment the THROW, RETURN, or
GO commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, it is possible for a throw or non-local exit
to be effectively "stopped" by an UNWIND-PROTECT cleanup clause that
performs a non-local transfer of control to a passed-over exit.
Some implementations crash or otherwise generate garbage code for
non-local exits from cleanup clauses of UNWIND-PROTECT.
Cost to Implementors:
No currently valid implementation will be made invalid by the MINIMAL
proposal. Some implementors may wish to add error checks if they
do not already have them.
MEDIUM would have a high cost for those implementations that currently
have shorter extent.
Cost to Users:
Most user programs don't do this, so there is likely little cost
of converting existing code in any case. In any case, current implementations
differ enough that this issue ostensibly does not
affect current portable programs. Some users might have code that
relies on the "unstoppable loops" that can be created with the MEDIUM
proposal.
Benefits:
Either proposal would make Common Lisp more precisely defined.
Cost of non-adoption :
The semantics of exits will remain ambiguous.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
This issue is controversial. It was first discussed under the issue
named UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT. The issue was recast as
the more global one of "extent of exits" rather than the specific
one of "what happens if a cleanup in an UNWIND-PROTECT does a non-
local exit", but the problem cases for both topics are the same.
The goal of the MINIMAL proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. The MEDIUM proposal
defines the extent of an exit to end at the last moment possible
within some particular reference implementation. It has
a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal, not considered
here, would duck the issue by outlawing all non-local exits from UNWIND-PROTECT
cleanup forms. That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
An argument for the MEDIUM proposal was made based on the example:
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
Since there is no reason for FOO and BAR not to be treated interchangeably,
calling this an error would be inappropriate.
It was argued that the MINIMAL proposal is equivalent to practically
outlawing non-local exits from UNWIND-PROTECT cleanup clauses, because
there is no general way to determine the target of the non-local exit
that caused the cleanup clause to be invoked.
The following example was offered as an argument against MINIMAL. Given:
(block nil
(handler-case
(unwind-protect (return)
(error "foo")) ;probably an error, under the proposal
(error ()
(print "foo"))))
If the ERROR handler has the same scope and extent a CATCH in the same place
would have (and that seems reasonable, though I'm not certain that the
condition system specifically requires that interpretation), then the handler
will be apparent to the call to ERROR, but will no longer be a valid target
(its extent was exited by the RETURN in the UNWIND-PROTECT body).
The extent of an object with dynamic extent is the extent of the form
which created it. Code which is executed "within" that form is within
the extent of the object(s). This applies to all dynamic objects, such
as special variable bindings, not just exits. Actually, I think the intent
of the implementation note on p.142 is fairly clear and supports this
interpretation. The supposedly ambiguous use of "frame" should be read
as something like "form which establishes a dynamic extent". It might be
clearer if the last sentence were changed to read something like:
"On the second pass the stack is actually unwound. Each form which establishes
a dynamic extent is undone in reverse order of creation until the matching
CATCH is reached. The meaning of undoing a form depends on the type of form.
For UNWIND-PROTECT, it means executing the cleanup forms. For CATCH it means
removing the CATCH tag. For dynamic bindings it means undoing the binding,
restoring the previous saved value. {This is not an exhaustive listing of the
possibilities.}"
∂08-Jan-89 2334 CL-Cleanup-mailer Re: Issue FIXNUM-NON-PORTABLE, v4
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 23:34:11 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 JAN 89 23:33:01 PST
Date: 8 Jan 89 23:31 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue FIXNUM-NON-PORTABLE, v4
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Sat, 31 Dec 88
19:47:14 PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890108-233301-3546@Xerox>
The portable use of FIXNUMs that convinced me came from applications that
wanted to use, say, a list of fixnums instead of a bit vector or a bignum
as an efficient representation of an arbitrary length sequence of bits.
For such an application, the FIXNUM type is ideal: it is the largest
"efficient" set of integers, and any explicit ranged integer type specifier
would not have the right properties.
I thought it was a legitimate portable use of the FIXNUM tpe. It is really
only a portable use of FIXNUM if FIXNUM is constrained to be a "reasonable"
size, however; e.g., it doesn't work if MOST-POSITIVE-FIXNUM is negative!
Constraining FIXNUM to be a reasonable size also makes other uses of FIXNUM
more legitimate. Perhaps we could make FIXNUM more useful if we required
MOST-POSITIVE-FIXNUM to be at least as big as ARRAY-DIMENSION-LIMIT or
CHAR-CODE-LIMIT or could be guaranteed to hold the largest "count" of
objects, e.g., that LENGTH always returns a FIXNUM. An alternative would be
to invent new types, e.g.,
(deftype array-dimension () `(integer 0 ,array-dimension-limit))
What should the name of "an integer big enough to count objects" be?
∂08-Jan-89 2357 CL-Cleanup-mailer Re: Issue: FORMAT-ROUNDING (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 23:57:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 JAN 89 23:54:26 PST
Date: 8 Jan 89 23:53 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FORMAT-ROUNDING (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 14 Nov 88 15:12 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890108-235426-3563@Xerox>
My belief is that we've decided we don't like this issue as stated. Would
it be appropriate to require that IEEE-FLOATING-POINT on *features* implies
the round-to-nearest algorithm?
∂08-Jan-89 2359 CL-Cleanup-mailer Re: Issue: FUNCTION-COERCE-TIME (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 23:59:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 23:58:44 PST
Date: 8 Jan 89 23:58 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-COERCE-TIME (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 13 Oct 88 17:03 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890108-235844-3572@Xerox>
Kent:
This one looks good for you to work on, if you're looking for priorities.
We released a draft at the last meeting, but couldn't get said what we
wanted.
I'll try not to send too many "priorities" your way...
∂09-Jan-89 0013 CL-Cleanup-mailer Re: Issue GC-MESSAGES (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 00:13:22 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 00:08:21 PST
Date: 9 Jan 89 00:07 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue GC-MESSAGES (Version 2)
In-reply-to: Dan L. Pierson <pierson@mist.encore.com>'s message of Tue, 03
Jan 89 13:53:40 EST
To: cl-cleanup@sail.stanford.edu
Message-ID: <890109-000821-3579@Xerox>
I sent a note to cl-editorial. I had a proposal for "unsolicited messages"
which is handles only those things like auto-load heralds and GC messages.
I think that LOAD and COMPILE progress notices are "solicited", at least by
LOAD.
Maybe this just subsumes GC-MESSAGES or should be handled under this name?
Issue: UNSOLICITED-MESSAGES
Problem: Is it legal for an implementation to produce unsolicited output,
e.g., GC notifications, autoload heralds, and progress messages from
COMPILE-FILE or LOAD?
Proposal: UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS
Unsolicited messages, such as GC notifications and autoload heralds, if
they are produced by an implementation, should not be directed to
*standard-output*, *error-output*. If an implementation produces them, they
may be produced on a stream that is not "shared" with any of the streams
that a user might redefine or redirect. (This really means that it is OK to
direct such notifications to *terminal-io* since a user may not redirect
*terminal-io*.)
Messages such as progress reports from LOAD and COMPILE are "solicited",
and are not covered by this issue. See issue COMPILE-AND-LOAD-VERBOSE.
∂09-Jan-89 0644 CL-Cleanup-mailer Re: Issue FUNCTION-COMPOSITION
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 9 Jan 89 06:44:18 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac16627; 9 Jan 89 8:57 EST
Received: from draper.com by RELAY.CS.NET id ae22894; 9 Jan 89 8:41 EST
Date: Mon, 9 Jan 89 08:02 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue FUNCTION-COMPOSITION
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
I like KMP's suggestion of CONSTANTLY.
∂09-Jan-89 0644 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 1)
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 9 Jan 89 06:44:30 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa16646; 9 Jan 89 8:57 EST
Received: from draper.com by RELAY.CS.NET id af22894; 9 Jan 89 8:41 EST
Date: Mon, 9 Jan 89 08:38 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: REAL-NUMBER-TYPE (version 1)
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
Hold on. How should the following be handled:
(declare (type (real 3.1415926 71/7) x))
...or (typep x '(real 3.1415926 71/7))?
When the type determination is made, how is the coercion of x to be done?
Must x be coerced from rational to float, or from float to rational, in
order to do the type check? Should RATIONAL or RATIONALIZE be used? ETc.,
etc., etc.
∂09-Jan-89 0933 CL-Cleanup-mailer Meeting in Hawaii
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 09:33:25 PST
Received: from fafnir.think.com by Think.COM; Mon, 9 Jan 89 12:26:04 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 9 Jan 89 12:30:33 EST
Received: by verdi.think.com; Mon, 9 Jan 89 12:29:16 EST
Date: Mon, 9 Jan 89 12:29:16 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8901091729.AA21924@verdi.think.com>
To: masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 5 Jan 89 23:20 PST <890105-232040-193@Xerox>
Subject: Meeting in Hawaii
Date: 5 Jan 89 23:20 PST
From: masinter.pa@xerox.com
OK:
Enough people can come Sunday that we'll meet Sunday afternoon to
decide/confirm what issues we will bring before the main X3J13 committee
for voting in plenary.
I'll be there late Sunday afternoon. I'll hunt up the room as
soon as I arrive from the airport.
--Guy
∂09-Jan-89 1020 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 10:19:56 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 10:15:58 PST
Date: 9 Jan 89 10:15 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REAL-NUMBER-TYPE (version 1)
In-reply-to: "Steve Bacher (Batchman)" <SEB1525@draper.com>'s message of
Mon, 9 Jan 89 08:38 EST
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890109-101558-4153@Xerox>
Surely it must use the same mechanism that <= and < do...
∂09-Jan-89 1059 CL-Cleanup-mailer Issues: REQUIRE-PATHNAME-DEFAULTS and LOAD-TRUENAME
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 10:59:38 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 10:54:31 PST
Date: 9 Jan 89 10:43 PST
From: masinter.pa@Xerox.COM
Subject: Issues: REQUIRE-PATHNAME-DEFAULTS and LOAD-TRUENAME
To: cl-cleanup@sail.stanford.edu
Message-ID: <890109-105431-4260@Xerox>
I had this stuff filed under the name LOAD-TRUENAME. But do they really
want to modify the default pathname for LOAD, or is it really REQUIRE? If
REQUIRE did have a default pathname, should it be the same as LOADs?
Somehow I don't think we will get away from the issue of "default loading
behavior" merely by outlawing REQUIRE.
----- Begin Forwarded Messages -----
Date: Tue, 13 Dec 88 20:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Possible issue: LOAD-TRUENAME
To: Dave.Touretzky@cs.cmu.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Masinter.PA
In-Reply-To: <2131.598064664@DST.BOLTZ.CS.CMU.EDU>
I agree that the issue is one that comes up a lot.
I think Genera offers a variable that lets you know what file is being
loaded. It might hold the name of the source file in a binary file load,
I forget.
For CL, maybe a variable (or function) to give the truename of the file
being LOADed or a list of the truenames of all files being loaded (most
recent first). A variation on this facility for use in COMPILE-FILE would
be useful as well.
Would that level of functionality suffice?
[I'm leary about your suggestion of LOAD binding variables that people
already assume LOAD doesn't bind. As to adding weird special-purpose
keywords to LOAD, knowing the name of the file being loaded may be
useful to other things besides LOAD, so I'd rather provide a more
general facility for getting at this information that would suffice for
other uses.]
Masinter may tell me it's too late to consider this kind of change,
but especially since there's a recognition that REQUIRE and PROVIDE are
bankrupt, and since CLtL's pathname stuff doesn't address all the file
problems which commonly come up in portable programs, maybe I can sneak
this in under the umbrella of a number of other file- (ok, pathname-)
related proposals we're about to hit X3J13 with if we come up with
something
sufficiently concrete and non-controversial in a hurry.
Some straw men:
- Variables *LOAD-TRUENAME* and *COMPILE-FILE-TRUENAME* which hold the
truename of the innermost file being loaded or compiled, respectively,
during the dynamic invocation of LOAD and COMPILE-FILE.
- Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold lists
of the truenames of all files being loaded or compiled, respectively,
during the dynamic invocation of LOAD and COMPILE-FILE.
- Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
((LOAD truename) (COMPILE-FILE truename) ...)
during the dynamic invocation of LOAD and COMPILE-FILE.
Better names solicited, of course.
----- Next Message -----
Sender: Common-Lisp-mailer%SAIL.Stanford:EDU:Xerox
Date: 14 Dec 88 08:45
From: MURRAY%cs.umass:EDU:Xerox
Subject: RE: load defaults
To: common-lisp%sail.stanford:EDU:Xerox
Return-Path: <Common-Lisp-mailer@SAIL.Stanford.EDU>
Redistributed: Xerox-Common-Lisp↑.x
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 14 DEC 88
08:45:49 PST
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU
with TCP; 14 Dec 88 08:13:15 PST
Received: from vax2.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
id AA02232; Wed, 14 Dec 88 11:14:26 est
Message-Id: <8812141614.AA02232@crash.cs.umass.edu>
Original-Date: Wed, 14 Dec 88 11:11 EST
X-Vms-To: IN%"common-lisp@sail.stanford.EDU"
> From: Dave.Touretzky@B.GP.CS.CMU.EDU
>I have a problem with the way Common Lisp says pathname defaults should be
> handled during load...
My initial reaction is that you should be using some sort of defsystem,
which gives you much more control over sets of files.
But maybe you're trying to run bare-bones.
>1. Anybody know a *portable* trick I can use to get embedded calls to LOAD
>to use the parent file's pathname as a default?
There is no portable way to find out what pathname is currently being
loaded. The portable way to get your desired behavior is simply to define
your own
load function that will bind *DEFAULT-PATHNAME-DEFAULTS* to the file it
is loading before it calls the real load.
(defun default-load (input &rest args)
(let ((*default-pathname-defaults* (merge-pathnames input)))
(apply 'load *default-pathname-defaults* args)))
>2. How terrible would it be for LOAD to rebind *DEFAULT-PATHNAME-DEFAULTS*
?
Probably not too terrible, but it does create another instance of
a problem that some people have complained about. By having LOAD bind
a special variable, it make it impossible to have the contents of a
file side-effect that variable after the load. This is a current problem
with *package*.
>3. Alternatively, what would people think of adding a :PARENT-PATH keyword
>to LOAD. With a value of T this keyword would mean "if this is an
embedded
>load, get default pathname information from the pathname of the parent
>file" ?
Surely you jest!
Kelly Murray
----- Next Message -----
Sender: Common-Lisp-mailer%SAIL.Stanford:EDU:Xerox
Date: 14 Dec 88 10:21
From: cperdue%Sun:COM:Xerox
Subject: RE: load defaults
To: Dave.Touretzky%B.GP.CS.CMU:EDU:Xerox, MURRAY%cs.umass:EDU:Xerox,
common-lisp%sail.stanford:EDU:Xerox
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
From: cperdue@Sun.COM (Cris Perdue)
To: Dave.Touretzky@B.GP.CS.CMU.EDU, MURRAY@cs.umass.EDU,
common-lisp@sail.stanford.EDU
Subject: RE: load defaults
Return-Path: <Common-Lisp-mailer@SAIL.Stanford.EDU>
Redistributed: Xerox-Common-Lisp↑.x
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 14 DEC 88
10:21:42 PST
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Dec 88 09:59:23
PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA28669; Wed, 14
Dec 88 09:59:57 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA27264; Wed,
14 Dec 88 09:56:35 PST
Received: by clam.sun.com (3.2/SMI-3.2) id AA14360; Wed, 14 Dec 88 09:57:31
PST
Original-Date: Wed, 14 Dec 88 09:57:31 PST
Message-Id: <8812141757.AA14360@clam.sun.com>
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
Some implementations of Common Lisp include a special variable
with a name like *source-pathname*, which is bound appropriately
by LOAD. This supports what is commonly known as "source code
recording" and if added to Common Lisp would meet needs such
as Touretzky's. We have found need for this at Sun and would
be happy to see such a thing in the language at some time.
-Cris
----- Next Message -----
Sender: Common-Lisp-mailer%SAIL.Stanford:EDU:Xerox
Date: 14 Dec 88 16:49
Reply-to: Dave.Touretzky%cs.cmu:EDU:Xerox
Subject: Re: load defaults
In-Reply-to: Your message of Wed, 14 Dec 88 11:11:00 -0500.
<8812141614.AA02232@crash.cs.umass.edu>
From: Dave.Touretzky%B.GP.CS.CMU:EDU:Xerox
To: common-lisp%sail.stanford:EDU:Xerox
Return-Path: <Common-Lisp-mailer@SAIL.Stanford.EDU>
Redistributed: Xerox-Common-Lisp↑.x
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 14 DEC 88
16:43:13 PST
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Dec
88 16:19:18 PST
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 14 Dec 88
19:17:08 EST
Original-Date: Wed, 14 Dec 88 19:16:51 EST
Message-ID: <3154.598148211@DST.BOLTZ.CS.CMU.EDU>
> Date: Wed, 14 Dec 88 11:11 EST
> From: MURRAY@cs.umass.EDU
>
> There is no portable way to find out what pathname is currently being
> loaded. The portable way to get your desired behavior is simply to
> define your own load function that will bind *DEFAULT-PATHNAME-DEFAULTS*
> to the file it is loading before it calls the real load.
> (defun default-load (input &rest args)
> (let ((*default-pathname-defaults* (merge-pathnames input)))
> (apply 'load *default-pathname-defaults* args)))
This is a nice idea, but it doesn't solve my problem. The user would have
to type in the whole definition before he could use it to load the header
file I referred to. I want to avoid inconveniencing the user; he should be
able to just start up a fresh Lisp, LOAD a single header file, and have
everything else happen automatically.
I like KMP's proposals. I like the second one best: have separate
variables for files being loaded and files being compiled, and use them to
maintain a stack so we can see the nesting of loads within files.
-- Dave
----- Next Message -----
Sender: Common-Lisp-mailer%SAIL.Stanford:EDU:Xerox
Date: 16 Dec 88 01:41
From: jonl%lucid:COM:Xerox
In-Reply-to: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Tue, 13 Dec 88
20:04:24 EST <2131.598064664@DST.BOLTZ.CS
Subject: file loading query
To: Dave.Touretzky%cs.cmu:EDU:Xerox
cc: common-lisp%sail.stanford:EDU:Xerox
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
From: Jon L White <jonl@lucid.com>
To: Dave.Touretzky@cs.cmu.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Tue, 13 Dec 88
20:04:24 EST <2131.598064664@DST.BOLTZ.CS.CMU.EDU>
Subject: file loading query
Return-Path: <Common-Lisp-mailer@SAIL.Stanford.EDU>
Redistributed: Xerox-Common-Lisp↑.x
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 16 DEC 88
01:41:40 PST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Dec 88 01:22:59
PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id
AA00971g; Fri, 16 Dec 88 01:20:08 PST
Received: by bhopal id AA20998g; Fri, 16 Dec 88 01:22:08 PST
Original-Date: Fri, 16 Dec 88 01:22:08 PST
Message-Id: <8812160922.AA20998@bhopal>
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
re: 1. Anybody know a *portable* trick I can use to get embedded calls to
LOAD
to use the parent file's pathname as a default?
I doubt that there's a portable trick. Lucid Common Lisp supports an
extension as follows:
(defvar *load-pathname* nil
"During a load, this is bound to the pathname of the file being
loaded.")
and ocasionally it is used to find out what directory the currently
loading file is on, so that a related file can be loaded from the same
directory.
-- JonL --
----- End Forwarded Messages -----
∂09-Jan-89 1119 CL-Cleanup-mailer Re: Issue: EXIT-EXTENT (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 11:18:53 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 11:06:54 PST
Date: 9 Jan 89 11:01 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXIT-EXTENT (Version 6)
In-reply-to: masinter.pa's message of 8 Jan 89 22:47 PST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-110654-4306@Xerox>
I guess I want to add my personal feeling on this issue:
I'm willing to vote for MINIMAL on the grounds that, although it isn't the
cleanest semantics, it is consistent with the goal of allowing
high-performance implementations, and we have ample documentation that some
implementations benefit considerably by this; secondarily on the grounds
that MEDIUM would be a serious incompatibility for some implementations. I
wasn't willing to vote for MINIMAL on the grounds that MEDIUM couldn't be
described or understood, which is why I put effort into describing MEDIUM
even though I'm willing to vote for MINIMAL.
Maybe I wasted my time as far as the outcome is concerned, but I think
we'll have to defend the positions we take well into the future, that they
were well-considered and that decisions were made on technical grounds.
∂09-Jan-89 1125 CL-Cleanup-mailer re: Issue: EQUAL-STRUCTURE (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 11:25:08 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JAN 89 11:20:39 PST
Date: 9 Jan 89 11:19 PST
From: masinter.pa@Xerox.COM
Subject: re: Issue: EQUAL-STRUCTURE (Version 5)
In-reply-to: your message of Sun, 8 Jan 89 15:48:41 PST
To: IIM%ECLA@ECLC.USC.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-112039-4344@Xerox>
You've uncovered an ambiguity in the spec for EQUALP that I
hadn't thought of before. I think your analysis points out that
EQUALP's description should mention HASH-TABLEs as a
special case. There are three possibilities: (1) EQUALP uses EQ
on hash tables, (2) EQUALP descends hash tables, (3) it isn't
specified. If EQUALP were to descend hash tables, we'd have
to say how: I'd guess that you'd have to compare the set of
keys using the hash table test function, and then the values
corresponding to the keys using EQUALP. I like specified better
than unspecified, and EQ better than descending.
(For the rest of cl-cleanup, the relevant part of Kim's message
is...
Date: Sun, 8 Jan 89 15:48:41 PST
From: IIM%ECLA@ECLC.USC.EDU
Subject: re: Issue: EQUAL-STRUCTURE (Version 5)
To: masinter.pa
cc: IIM%ECLA@ECLC.USC.EDU
In-Reply-To: <890108-134500-3303@Xerox>
> Date: 8 Jan 89 13:44 PST
> From: masinter.pa@Xerox.COM
>
> You're right. Can I talk you into helping draft a version that says what we
> mean? Kent and I are burned out on this issue, apparently.
>
> Preferably so we can have a version for voting on...
> Let me know one way or another asap.
Well, I'd like to help, but I have two serious problems.
First, I expect to have very little time to devote to X3J13 issues for the next
few weeks, other than attending the meeting and discussing things there, since
starting tomorrow I'm going to be embarking on a fairly major low-level change
in our implementation, the completion of which is on the critical path for the
completion of several other projects here. I'm going to try to address as many
things as I can before I go home today (even if it means not leaving until
tomorrow) but after that I'm likely to be pretty unresponsive for a while.
Second, I'm really not certain myself what it is "we mean", much less what the
"right thing" is, so it's hard for me write it up. The example problem I keep
having trouble with is hash-tables. I can't think of any good reason why
EQUALP should specifically recognize them, yet I also think it has to.
Consider the following:
1. Given 2 EQ hash-tables H1 and H2
2. For some set of keys and associated values, install them in both H1 and H2,
in the same order.
3. Invoke the garbage collector. (I'm assuming that this will "invalidate" the
hashing in the tables, requiring a rehash to occur on at least some
operations.)
4. Perform some operation on H1 which does not change the key mapping, but
causes a rehash to occur due to the recent gc.
It is very likely that under a simple component-wise comparison, H1 and H2 are
now no longer equivelent. Worse yet, I can readily construct situations in
multi-processing or interruptable environments in which a simple component-wise
comparison implementation of EQUALP will return false for (equalp x x), where x
is an eq hash-table.
So we have an existance proof of an ill-defined case. I think you'll have a
hard time convincing me either that this is the only such case or that these
problems don't arise in "user code". And it seems to me quite likely that the
set of problem cases will vary between implementations. What do we do with
such things? I'm afraid I don't have what I consider to be a good answer. I
suppose we could punt by saying that EQUALP does component-wise comparisons
always, and add a caveat that this isn't necessarily useful or even "correct"
for some datatypes in some implementations. I don't think we can say anything
about signaling errors in the bad cases, since if user-defined objects can have
these problems then there really isn't a way to detect when to signal.
Besides, I sort of dislike the idea of an equality predicate which signals
errors.
kab
-------
∂09-Jan-89 1142 CL-Cleanup-mailer Re: Ballots, please
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 11:42:01 PST
Date: 9 Jan 1989 14:42-EST
Sender: ROSENKING@A.ISI.EDU
Subject: Re: Ballots, please
From: ROSENKING@A.ISI.EDU
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 9-Jan-89 14:42:06.ROSENKING>
In-Reply-To: <890106-002339-193@Xerox>
I expect to get my ballot in by late Tuesday (10 January).
∂09-Jan-89 1318 CL-Cleanup-mailer Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 13:18:45 PST
Received: by ti.com id AA00427; Mon, 9 Jan 89 12:35:39 CST
Received: from Kelvin by tilde id AA05460; Mon, 9 Jan 89 12:26:31 CST
Message-Id: <2809362537-10236580@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 9 Jan 89 12:28:57 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Kim A. Barrett" <IIM@ECLA.USC.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
In-Reply-To: Msg of Mon 2 Jan 89 17:31:11-PST from Kim A. Barrett <IIM@ECLA.USC.EDU>
> Proposal (SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT)
>
> Extend SUBTYPEP to accept an optional third argument. This argument should be
> either NIL, the &environment argument received by a macro expander function,
> or the environment argument received by an *evalhook* or *applyhook* function.
> This argument is used to distinguish between compile-time and run-time
> environments.
I don't see any point in mentioning *EVALHOOK* environments here since
there isn't any facility for local type declarations comparable to
MACROLET for local macros.
∂09-Jan-89 1320 CL-Cleanup-mailer Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 13:20:21 PST
Received: by ti.com id AA00423; Mon, 9 Jan 89 12:35:34 CST
Received: from Kelvin by tilde id AA05368; Mon, 9 Jan 89 12:20:25 CST
Message-Id: <2809362147-10213162@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 9 Jan 89 12:22:27 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Cc: "Kim A. Barrett" <IIM@ECLA.USC.EDU>, cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
In-Reply-To: Msg of Sat, 7 Jan 89 12:24 EST from Richard Mlynarik <Mly@AI.AI.MIT.EDU>
> Not so. Consider compiler optimisations of (MAKE-ARRAY # :ELEMENT-TYPE #)
> When I last wrote a CL type system I needed a mess of parallel
> COMPILER-SUBTYPEP and COMPILER-UPGRADE-ARRAY-ELEMEN-TYPE (and so forth)
> functions. Using compilation-environment technology would have been far
> preferable.
>
> I give MAKE-ARRAY optimisation merely as an example -- I feel `user'
> code has the same sorts of needs.
On the Explorer, both TYPEP and SUBTYPEP already implicitly use the
compile-time environment when they are called from within COMPILE-FILE.
Consequently, uses of these in macro expanders will see type definitions
earlier in the same file without the macro writer needing to do anything
special, so this capability could be used a lot without anyone realizing
it. I think it would be cleaner if these functions accepted optional
environment arguments, which default to the compilation environment when
within COMPILE-FILE.
∂09-Jan-89 1553 CL-Cleanup-mailer Re: Ballots, please
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jan 89 15:52:48 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08549; 9 Jan 89 23:40 GMT
Date: Mon, 9 Jan 89 23:42:09 GMT
Message-Id: <12148.8901092342@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Ballots, please
To: cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: masinter.pa@com.xerox's message of 6 Jan 89 00:23 PST
>
> We've gotten very few ballots back. Please let us know soon if you plan to
> vote even if you can't get your ballot in right away; we'll need some time
> to respond to some of the comments and prepare new versions for the
> meeting!
I will try very hard to send mine tomorrow (but I mean after some
hours of sleep rather than after 20 minutes).
Cheers,
Jeff
∂09-Jan-89 1609 CL-Cleanup-mailer Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 9 Jan 89 16:09:00 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 257602; Mon 9-Jan-89 19:06:33 EST
Date: Mon, 9 Jan 89 19:06 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
To: Gray@DSG.csc.ti.com, Mly@AI.AI.MIT.EDU
cc: IIM@ECLA.USC.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <2809362147-10213162@Kelvin>
Message-ID: <19890110000602.8.GSB@GANG-GANG.SCRC.Symbolics.COM>
Date: Mon, 9 Jan 89 12:22:27 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> Not so. Consider compiler optimisations of (MAKE-ARRAY # :ELEMENT-TYPE #)
> When I last wrote a CL type system I needed a mess of parallel
> COMPILER-SUBTYPEP and COMPILER-UPGRADE-ARRAY-ELEMEN-TYPE (and so forth)
> functions. Using compilation-environment technology would have been far
> preferable.
>
> I give MAKE-ARRAY optimisation merely as an example -- I feel `user'
> code has the same sorts of needs.
On the Explorer, both TYPEP and SUBTYPEP already implicitly use the
compile-time environment when they are called from within COMPILE-FILE.
Consequently, uses of these in macro expanders will see type definitions
earlier in the same file without the macro writer needing to do anything
special, so this capability could be used a lot without anyone realizing
it. I think it would be cleaner if these functions accepted optional
environment arguments, which default to the compilation environment when
within COMPILE-FILE.
The problem is defining "within" compile-file. This is what the environment
argument determines. A runtime call to make-array inside the guts of the
compiler (or other miscellaneous system code) which happens to be
unoptimized and calls subtypep should not be using type information from
the user's file.
∂09-Jan-89 1722 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jan 89 17:21:30 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa00553; 10 Jan 89 1:14 GMT
Date: Tue, 10 Jan 89 01:16:52 GMT
Message-Id: <12503.8901100116@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: REAL-NUMBER-TYPE (version 1)
To: CL-Cleanup@sail.stanford.edu
I support this proposal.
One of the advantages of Scheme over Common Lisp is that it
distinguishes between abstract numbers (real, complex, rational,
etc.) and representations (fixnum, ratio (well, that might be
both), etc.) I think Common Lisp should try to do the same.
∂09-Jan-89 1728 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 2)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jan 89 17:27:47 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa00610; 10 Jan 89 1:21 GMT
Date: Tue, 10 Jan 89 01:23:40 GMT
Message-Id: <12536.8901100123@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: REAL-NUMBER-TYPE (version 2)
To: CL-Cleanup@sail.stanford.edu
> Discussion:
>
> The name "non-complex number" is incorrect because future
> implementations may wish to include numerical types which are neither
> complex nor real. [e.g. pure imaginary numbers or quaternions]
>
> The name "scalar" is incorrect because the mathematical concept of
> scalar may indeed include complex numbers.
>
> Fortran and Pascal use the name "real" to mean what CL calls
> SINGLE-FLOAT. [More about F and P.]
Scheme uses REAL to mean more or less what's being proposed for CL.
∂09-Jan-89 1822 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 2)
Received: from WHITE.SWW.Symbolics.COM ([128.81.57.24]) by SAIL.Stanford.EDU with TCP; 9 Jan 89 18:21:47 PST
Received: from METAL-FLAKE.SWW.Symbolics.COM by WHITE.SWW.Symbolics.COM via CHAOS with CHAOS-MAIL id 229025; Mon 9-Jan-89 17:55:40 PST
Date: Mon, 9 Jan 89 17:57 PST
From: Marc Le Brun <MLB@WHITE.SWW.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 2)
To: Cassels@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@Sail.Stanford.EDU, DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM, rwg@WHITE.SWW.Symbolics.COM
In-Reply-To: <19890108162936.5.CASSELS@GROUSE.SCRC.Symbolics.COM>
Message-ID: <19890110015752.6.MLB@METAL-FLAKE.SWW.Symbolics.COM>
Date: Sun, 8 Jan 89 11:29 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Issue: REAL-NUMBER-TYPE
Forum: CLEANUP
References: Table 4-1.
Category: ADDITION
Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
and John Aspinall
08-JAN-89, Version 2 by Bob Cassels -- incorporate
Masinter's suggestion and make REAL a CLOS class
Status: For Internal Discussion
Problem Description:
There is no standard type specifier symbol for the CL type
'(OR RATIONAL FLOAT).
Proposal (REAL-NUMBER-TYPE:REAL):
I apologize for the size of this response, but since this is sort of a "dissenting opinion" I
felt it would be good to document the arguments as carefully as I could.
There are dangers in introducing the term REAL. It encourages the widespread confusion
between a computer type, REAL, which of necessity denotes a countable class of symbols, with
the mathematical object (which I'll call R), which is non-denumerable. This identification of
incommensurables has many unfortunate consequences, including ambiguous and inconsistent use
of "intuitive" models. Further, members of these sets which are commonly identified with
eachother (ie real numbers and their computer images) often have incompatible semantics.
The original Common Lisp specification did the world a service by eliminating this source of
potential confusion. If the term is to be reintroduced for pragmatic reasons, then it should
at least done very carefully, so as not to result in further propagation, even amplification,
of these problems. It doesn't seem either responsible or forward-looking to gloss over these
difficult issues.
Add a standard type specifier
(REAL low high)
which means
(OR (RATIONAL low high) (FLOAT low high))
The Discussion section below implies that future extensions should be considered here.
Suppose an implementation introduces new types which model members of R but which do not
satisfy this predicate. (For example, quadratic fields, or symbols denoting rational
multiples of (mathematical) pi, say). Is the implementation allowed to extend the type REAL
or not? I'd vote to allow extension, but in any case this should be stated. (Further, must
it so extend it?)
As with other such type specifiers, define that if the low and high
are omitted, the atomic specifier REAL may be used.
Clarify that NUMBER is equivalent to (OR REAL COMPLEX).
Suppose an implementation introduces new types which could considered numeric but which do not
satisfy this predicate. (For example, quaternions, as mentioned in the Discussion). Is the
implementation allowed to extend the type NUMBER or not? I'd vote to allow extension, but in
any case this should be stated. (Further, must it so extend it?)
Make REAL a built-in CLOS class.
Proposal (REAL-NUMBER-TYPE:REALP):
Add a specific data type predicate REALP which tests for membership in
this type. [By analogy with NUMBERP.]
Test Case:
If a programmer wishes to test for "a number between 1 and 10", the
only current CL types would be '(or (rational 1 10) (float 1 10)) or
something like '(and numberp (not complexp) (satisfies range-1-10))
with (defun range-1-10 (real) (<= 1 real 10)). Both of these are
likely less efficient, and certainly less expressive than '(real 1 10).
Rationale:
Mathematics has a name for (OR RATIONAL FLOAT) -- it is "real".
No.
1. As noted above R contains many "useful" elements (eg surds, mathematical pi or e) which can
have discrete symbolic representations but whose behavior is not accurately modeled by any
REAL element.
2. Under many circumstances the semantics of "typical" elements of REAL are quite distinct
from the elements of R with which they are commonly identified, leading to a variety of
situational interpretations as "intervals", "fuzzy numbers", etc which clearly do not belong
to the theory of R.
3. Conversely operations on elements of R conform to a semantics of "infinite precision"
obviously unattainable by REALs.
4. REAL also may contain specific entities (such as -0.0) not in R.
5. Because of finite range limitations REAL further does not consistently "cover" R.
Sometimes this is dealt with as an error, sometimes with the introduction of non-analytic
semantics (eg setting underflows to zero), sometimes by introducing non-standard entities
partially or wholly outside R (eg the various "infinities", or the IEEE "Not-A-Number"s which
(at least in Symbolics CL) paradoxically satisfy NUMBERP!).
6. Since there is no "floating canonicalization", the type REAL contains multiple distinct
images of certain elements of R (notably zero, many rationals, and many flonums which exist in
more than one so-called "precision").
This class is important because it is all the numbers which can be ordered.
Agreed that the ordering property of R is important. It might be possible to have CL so
define REAL specifically as some kind of maximal well-ordered set (though this might be
tricky, in order to exclude characters as potential numbers, for example).
(And, mathematically anyway, one might even ask for more rigor regarding the term "ordered",
considering, for example, Conway numbers. This would be a gratuitous comment except for IEEE
having already opened the Pandora's box of non-standard numbers.)
Throughout the "Numbers" chapter, the phrase "non-complex number" is used.
MAX, MIN, p. 198 "The arguments may be any non-complex numbers."
CIS p. 207 "The argument ... may be any non-complex number."
Presumably this is to be read as a proposal to substitute "real" for "non-complex number"?
Note that these restrictions are apparently motivated by different properties: in some cases
ordering, in others an aversion to imaginary algebra (eg the mystifying restrictions on CIS,
COMPLEX et al). Depending on the extension policy adopted that substitution might or might
not retain its validity under an extension (eg symbols for rational multiples of mathematical
pi aren't (OR RATIONAL FLOAT) but might be an acceptable, indeed useful, subdomain for CIS).
Current Practice:
Probably nobody does this.
Cost to Implementors:
Some work is necessary to add this name. But since the underlying
type already exists the amount of work should be minimal.
Cost to Users:
Since this is an upward-compatible extension, it may be ignored by
users.
Cost of Non-Adoption:
Occasional inconvenience and/or inefficiency.
Benefits:
Mathematical clarity.
Arguable.
Ability to do CLOS method dispatch on the type.
Aesthetics:
As mentioned under "rationale," this would be a more concise way to
express a common programming idiom.
Discussion:
The name "non-complex number" is incorrect because future
implementations may wish to include numerical types which are neither
complex nor real. [e.g. pure imaginary numbers or quaternions]
As noted above, the policy regarding possible extensions, either as future CL standards or
per-implementation, should be clarified in several respects.
The name "scalar" is incorrect because the mathematical concept of
scalar may indeed include complex numbers.
Fortran and Pascal use the name "real" to mean what CL calls
SINGLE-FLOAT. That should cause no significant problem, since a Lisp
program written using the type REAL will do mathematically what the
equivalent Fortran program would do. This is because Fortran's "real"
data-type is a subtype of the CL REAL type. The only differences
might be that the Lisp program could be less efficient and/or more
accurate.
This needs clarification. If by "equivalent Fortran program" is meant a FORTRAN program that
was specifically (heroically?) written to carefully model a CL program, then this begs the
question. If it means "a naive translation" between languages, then this is far from obvious
(eg a CL implementation might generate rationals, thereby maintain different information
through subsequent operations, and finally get results diverging significantly from the
FORTRAN program).
One could also easily imagine some careful conventional flonum-based numerical analysis being
thrown off by the introduction of a non-zero rational smaller than CL "epsilon", for example.
The assignation of "more accurate" is application-dependent and implementation-dependent.
A survey of several Fortran and Pascal books shows that the distinction
between INTEGER and REAL is that REAL numbers may have fractional
parts, while INTEGERs do not. Later discussions explain that REALs
cover a greater range. Much later discussions cover precision
considerations, over/underflow, etc. So the average Fortran or Pascal
programmer should be completely comfortable with the proposed Lisp
concept of REAL.
Agreed, the proposed type is an extension of what's commonly meant by the name REAL.
(Although there exist unusual systems where REALs are implemented by decimal rationals!)
While the "average programmer" may be comfortable, the differences between CL REALs and
conventional REALs and their implications should be carefully and thoroughly documented in the
standard (leaving aside the quagmire of confusion with regards to R).
∂09-Jan-89 1913 CL-Cleanup-mailer Re: Issue: OUTPUT-STREAM-P-EXAMPLE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 19:13:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 15:42:08 PST
Date: 9 Jan 89 15:35 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: OUTPUT-STREAM-P-EXAMPLE
In-reply-to: ROSENKING@A.ISI.EDU's message of 26 Oct 88 16:48 EDT
To: ROSENKING@A.ISI.EDU
cc: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <890109-154208-4993@Xerox>
I wish I had a better justification for saying (output-stream-p
(make-concatenated-stream) ) should return NIL.
I think part of it is lack of a theory of what OUTPUT-STREAM-P really
means.
∂09-Jan-89 1914 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 19:13:42 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 18:18:40 PST
Date: 9 Jan 89 18:16 PST
From: masinter.pa@Xerox.COM
Subject: Issue: SETF-SUB-METHODS (Version 5)
To: cperdue@Sun.COM (Cris Perdue)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-181840-5085@Xerox>
In your ballot, you said:
This does not seem to be the "right" choice of semantics, and I
believe that the presentation of the proposal needs substantial work
even if it is "right".
Can you help us? in what way is it wrong? what might be better? what
cases are unclear that we need to clarify?
∂09-Jan-89 1913 CL-Cleanup-mailer re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 19:13:29 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 17:25:29 PST
Date: 9 Jan 89 17:24 PST
From: masinter.pa@Xerox.COM
Subject: re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of 2 Jan 89 15:23
PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-172529-5043@Xerox>
Kim:
The proposal only implies that PEEK-CHAR is no longer equivalent to
READ-CHAR followed by UNREAD-CHAR when the stream in question is stream
created by MAKE-ECHO-STREAM. Certainly for any other stream, a string
stream, and any other stream that doesn't have ECHO behavior, PEEK-CHAR
could be implemented by READ-CHAR followed by UNREAD-CHAR. It probably
implies that synonym streams should "pass on" the PEEK-CHAR operation, and
that concatenated streams should also do so, but I'd be suprised if many
implementations didn't already do that.
This proposal does *not* necessarily affect what *TERMINAL-IO* does; only
with streams created by MAKE-ECHO-STREAM.
FYI, hardcopy & online versions have the typo "echos" fixed. Are there
others?
∂09-Jan-89 1913 CL-Cleanup-mailer Re: Issue: REST-LIST-ALLOCATION (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 19:13:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JAN 89 17:53:34 PST
Date: 9 Jan 89 17:52 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REST-LIST-ALLOCATION (Version 3)
In-reply-to: gz@spt.entity.com (Gail Zacharias)'s message of 5 Jan 89
18:06:05 EST (Thu)
To: gz@spt.entity.com (Gail Zacharias)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-175334-5056@Xerox>
My reading of CLtL is that no setting of the OPTIMIZE/SAFETY setting
requires checking for invalid arguments to CADR.
The only thing that SAFETY 0 does is allow you to turn off some of the
error checking that CLtL requires you normally to enforce.
∂09-Jan-89 1943 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 19:43:03 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 19:41:00 PST
Date: 9 Jan 89 19:40 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TAGBODY-CONTENTS (Version 5)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 3 Jan 89 00:25 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <890109-194100-5316@Xerox>
I wrote up this proposal in the current form, but I've had some second
thoughts as I'm trying to deal the ballot comments.
I've forgotten the reasons for allowing other types of objects in TAGBODY
bodies. I still like the part about duplicate elements was the part about
duplication, viz: duplicates are OK if there's no GO.
Walter's objections were not included in the proposal writeup, I've
discovered:
"I strongly disagree with the version 4 change to allow duplicate
tags as long as there is no GO to them. If one really wants to be
able to use NIL as a statement because of the way many people write
macros, then let's change the proposal to treat NIL as a statement,
and not as a tag. And the rationale about using symbols as dividers
in code sounds pretty weak to me--that what comments are for.
I never saw version 3 of the proposal, but it sounds more like what
I'd find reasonable, judging by the change history.
---Walter
"
I guess we can talk about this next week. I'm just saying I've probably
changed my mind -- not that this is an important issue.
∂09-Jan-89 1952 CL-Cleanup-mailer Re: Ballots, please
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 19:52:28 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 19:51:21 PST
Date: 9 Jan 89 19:50 PST
From: masinter.pa@Xerox.COM
Subject: Re: Ballots, please
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
message of Mon, 9 Jan 89 23:42:09 GMT
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
Message-ID: <890109-195121-5331@Xerox>
>>Message<<
∂09-Jan-89 1956 CL-Cleanup-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 19:56:40 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01625g; Mon, 9 Jan 89 19:51:50 PST
Received: by bhopal id AA11931g; Mon, 9 Jan 89 19:54:06 PST
Date: Mon, 9 Jan 89 19:54:06 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901100354.AA11931@bhopal>
To: masinter.pa@Xerox.COM
Cc: Gray@DSG.csc.ti.com, KMP@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 8 Jan 89 00:31 PST <890108-003143-3022@Xerox>
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
re: The meta-rules for backquote were derived "after the fact" as a way to
explain what backquote did; the use of APPEND and the equivalences there
were based on the old semantics of APPEND. Now that we've extended APPEND,
we have to change the meta-rules of backquote, . . .
Your assumption here can't be true -- The MacLisp implementation (and
others) carried out the now-debased optimization; yet the meta-rules
stand. I'm very leery of changing these meta rules unless QUUX signs
off on it -- every time I've been tempted to dicker with them, I find
out that they are much deeper than a cursory glanch would suspect. [I
thought Guy devised those "meta" rules -- if he didn't then the author
ought to be consulted.]
re: This requires fixing the example, so that
`((,a b) ,c ,@d)
will be interpreted as
(append (list (append (list a) (list 'b))) (list c) d)
As far as I can tell, this is consistent with the way that Lucid Common
Lisp's backquote works anyway.
But that's precisely what Greenwald reported as a bug! As I explained
in previous mail, Lucid has the bug because when the decision to
reaffirm the "new" semantics for APPEND was made, no one noticed (or
cared about?) the implications for backquote.
I think it would be putting the cart before the horse to try to
institutionalize the now-debased optimization into the semantics of
backquote, as a way around the bug. The advantage of not performing
this optimization is that the user need never be confused as to whether
or not ",@" will copy its argument, or share; currently a user can't be
sure because of the permitted ambiguity.
Note that Guy himself also acknowledged the validity of Greenwald's
complaint -- he claims that the _examples_ are invalid rather than
the rules. Your proposal is just the opposite -- to keep the examples
valid and alter the rules to contain the essence of the "optimization".
Date: Tue, 29 Nov 88 17:12:40 EST
From: gls@Think.COM
To: Greenwald@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, Greenwald@stony-brook.scrc.symbolics.com,
common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Tue, 29 Nov 88 14:05 EST <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
. . .
Because you sent the mail out to common-lisp@sail and not to
any of the X3J13 mailing lists, I assumed that you were asking
a question about the language as defined solely by the book.
In other words, I assume that the audience for the common-lisp
mailing list has not necessarily followed all of the X3J13 work.
It is true that eventual adoption of this cleanup item [APPEND-DOTTED?]
would invalidate the examples.
--Guy
Guy, wanna comment?
-- JonL --
∂09-Jan-89 2142 CL-Cleanup-mailer Issue: FORMAT-ROUNDING (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 21:42:17 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01686g; Mon, 9 Jan 89 21:37:44 PST
Received: by bhopal id AA12145g; Mon, 9 Jan 89 21:40:00 PST
Date: Mon, 9 Jan 89 21:40:00 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901100540.AA12145@bhopal>
To: masinter.pa@Xerox.COM
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 8 Jan 89 23:53 PST <890108-235426-3563@Xerox>
Subject: Issue: FORMAT-ROUNDING (Version 1)
re: My belief is that we've decided we don't like this issue as stated. Would
it be appropriate to require that IEEE-FLOATING-POINT on *features* implies
the round-to-nearest algorithm?
"round-to-nearest" isn't sufficient; it should be "IEEE round-to-nearest",
which has implications for "ties".
However, both Moon and I seemed to prefer not trying to specify something
in the standard for the case this issue is addressing.
-- JonL --
∂09-Jan-89 2203 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 22:03:35 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01692g; Mon, 9 Jan 89 21:59:21 PST
Received: by bhopal id AA12192g; Mon, 9 Jan 89 22:01:37 PST
Date: Mon, 9 Jan 89 22:01:37 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901100601.AA12192@bhopal>
To: masinter.pa@Xerox.COM
Cc: IIM%ECLA@ECLC.USC.EDU, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 9 Jan 89 11:19 PST <890109-112039-4344@Xerox>
Subject: Issue: EQUAL-STRUCTURE (Version 5)
Some months back, John Rose made a suggestion that two hashtables should
only be considered "equivalent" (for constant coalescing purposes) if
there are equal on a component-by-component basis; _and_ where component
indexing is by the set of hash-table keys. Several people (including
myself) supported this view, even though it makes descent into hash
tables a bit more complex than descent into simpler structures.
-- JonL --
∂09-Jan-89 2230 CL-Cleanup-mailer ballot
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 22:30:41 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA00602@EDDIE.MIT.EDU>; Tue, 10 Jan 89 01:28:10 EST
Received: by spt.entity.com (smail2.5); 9 Jan 89 22:54:47 EST (Mon)
To: cl-cleanup@sail.stanford.edu
Subject: ballot
Message-Id: <8901092254.AA08704@spt.entity.com>
Date: 9 Jan 89 22:54:47 EST (Mon)
From: gz@spt.entity.com (Gail Zacharias)
This ballot is the official position of Apple Computer.
"Yes if" means we won't vote for the proposal unless a condition is satisfied.
"Yes" with a comment means we'd like to see a change, but will vote for it
anyway.
Yes ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
Yes if ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
Flush the UPGRADED-xxx functions.
Yes CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Version 5, 5-Dec-88, Mailed 5 Dec 88
Would prefer to specify a value for CLOSE on closed streams. What's the
point of leaving it undefined?
Yes CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
No DECLARE-TYPE-FREE:ALLOW
Version 8, 7-Dec-88, Mailed 9-Dec-88
We'll probably support the LEXICAL option (not on the ballot).
Yes DECLARATION-SCOPE:NO-HOISTING
No DECLARATION-SCOPE:LIMITED-HOISTING
Version 4, 15-Nov-88, Mailed 9-Dec-88
Yes DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Version 4, 5-Dec-88, Mailed 5-Dec-88
A DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
Yes DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
Yes if DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
The proposal should state that the constraint applies only to the
arguments to the DEFSTRUCT macro. It does not constrain the STRUCTURE-CLASS
metaclass to require all slots to have STRING/= names.
Yes DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
Needs to specify whether the keyword or variable name is the slot name.
Yes DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
A DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
A DESCRIBE-INTERACTIVE:NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
No DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
A EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
No EXIT-EXTENT:MINIMAL
Yes EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
Yes EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
Yes if FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
Yes FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Version 4, 7-Dec-88, Mailed 12-Dec-88
We'll support TIGHTEN-DEFINITION iff TIGHTEN-FIXNUM-TOSS-BIGNUM fails.
A FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
Yes FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
A FUNCTION-COMPOSITION:NEW-FUNCTIONS
Yes if FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
If ALWAYS is renamed to CONSTANT or CONSTANTLY.
A FUNCTION-DEFINITION:FUNCTION-SOURCE
Version 2, 09-Dec-88 , Mailed 9 Dec 88
Yes FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
No FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
No HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Version 7, 8-Dec-88, Mailed 9-Dec-88
Should be functions.
C HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
As best we can tell, all this proposal says is that it is an error to
destructively modify elements of equal hash tables but ok to do so for eq
hash tables. We would support a simpler proposal stating this.
Yes HASH-TABLE-TESTS:ADD-EQUALP
Version 2, 8-Dec-88, Mailed 8 Dec 88
Yes IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
Yes LAMBDA-FORM:NEW-MACRO
Version 4, 22-Nov-88, Mailed 8-Dec-88
New special form would be even better.
Yes LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
Yes GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
Yes LISP-SYMBOL-REDEFINITION:DISALLOW
Version 5, 22-Nov-88, Mailed 8 Dec 88
No MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
Yes MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
Yes NTH-VALUE:ADD
Version 4, 8-Dec-88, Mailed 8 Dec 88
Clarify that NIL should be returned when index is larger than number of values
Yes PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
Yes if PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
Remove the description of "correctable" error to be signalled and handled.
This sort of detailed error protocol is not specified for any other function
and is not appropriate here.
Yes PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Version 1 27-Jun-88, Mailed 7 Oct 88
Yes PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
Yes PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
No PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
Yes RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Version 3, 9-Oct-88, Mailed 14-Oct-88
Yes RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
NIL should be allowed for start, allowing it for some arguments (count,
end) and not others (start) is too obscure.
Yes REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
Yes REST-LIST-ALLOCATION:NEWLY-ALLOCATED
No REST-LIST-ALLOCATION:MAY-SHARE
No REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
Yes RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
No ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
[The following are mutually exclusive]
No SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
No SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
Yes SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
Yes STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
Yes STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
Yes if STREAM-ACCESS:ADD-TYPES-ACCESSORS
No STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
No STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
The following paragraph from the description of OPEN-STREAM-P may
be misleading:
Streams are "open" until they have been closed with CLOSE, or, the
dynamic context of the creating/accessing macros of WITH-OUTPUT-TO-STRING,
WITH-OPEN-FILE, WITH-INPUT-FROM-STRING, WITH-OPEN-STREAM, have been
exited.
This may be taken to imply that the stream still exists (as a closed stream)
even after the dynamic extent of the WITH-xxx form is exited. Because these
stream objects have dynamic extent, they cannot be referenced in any way once
the WITH-xxx form exits. (They can't even be passed to OPEN-STREAM-P.) As a
practical example, the streams could be stack-consed, and future use could
cause crashes. The reference to exited WITH-xxx forms should be deleted, or
explanatory text should be added.
No STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
Our opposition is based on the following points:
1) The defining property of WRITE-SPACE (that it must write exactly the number
of units given) is too restrictive. For example it may not be possible to
write whitespace to a stream in units smaller than a #\space character, if the
stream is associated with a (multi-font) ascii file or editor buffer (since
there may be no ascii character available that can be inserted in the
file/buffer to represent the whitespace). An implementation cannot simply
make the unit size equal to the width of a #\space character, because a
subsequent increase in font-size would again make the unit smaller than a
current #\space character.
2) The "additional properties" of PRINTED-WIDTH (i.e. 8 and 9, stating that
printed-widths are additive) are incompatible with some non-Roman scripts. For
example, in the Arabic language the glyphs used for characters are dependent
on the surrounding characters: in our Arabic implementation of Object Logo,
editing causes surrounding characters to change shape (and width) according to
their new context. The restrictions on PRINTED-WIDTH would make it difficult
to similarly incorporate the context-sensitive character portrayal features of
the Macintosh into our Common Lisp implementation.
3) In general we feel that the proposal is premature, given the current state
of i/o standards. We would prefer to wait for a complete solution (i.e. a
real graphics standard and extended characters set standard). We feel that
the current proposal is too specific and problematical for a proper place in
Common Lisp. For now, the desired features are probably best obtained via
implementation-specific functions.
Yes SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
Yes SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
Yes SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
Yes if TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
We support forbidding extensions, but oppose allowing duplicate and
unreachable tags. Instead we would prefer clarifying that () is a form
and not a valid tag.
Yes TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
Yes TEST-NOT-IF-NOT:FLUSH-ALL
Yes TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
Yes TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
Yes UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
Yes VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
∂09-Jan-89 2233 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 22:33:07 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 22:30:56 PST
Date: 9 Jan 89 22:30 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EQUAL-STRUCTURE (Version 5)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Mon, 9 Jan 89
22:01:37 PST
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, IIM%ECLA@ECLC.USC.EDU,
cl-cleanup@sail.stanford.edu
Message-ID: <890109-223056-5490@Xerox>
What is current practice in this area? What does EQUALP do in current
implementations on hash tables?
I'd wouldn't want to make everybody extend EQUALP where nobody does it.
∂09-Jan-89 2238 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 22:38:31 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JAN 89 22:37:25 PST
Date: 9 Jan 89 22:36 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
To: alarson@src.honeywell.com (Aaron Larson)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-223725-5504@Xerox>
Re: "Confused, why string= on the names. Does that mean that foo:a and
bar:a cannot both be slots in the same structure? (check where accessors
are interned)."
Yes, DUPLICATES-ERROR means that you cannot have FOO:A and BAR:A both a
slot in the same DEFSTRUCT structure.
I think this is an implication of the wording there and no amendement is
needed, but will add this clarification if there is disagreement.
∂09-Jan-89 2335 CL-Cleanup-mailer [chapman%aitg.DEC@decwrl.dec.com: vote]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 23:35:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 23:34:40 PST
Date: 9 Jan 89 23:33 PST
From: masinter.pa@Xerox.COM
Subject: [chapman%aitg.DEC@decwrl.dec.com: vote]
To: cl-cleanup@sail.stanford.edu
Message-ID: <890109-233440-5555@Xerox>
----- Begin Forwarded Messages -----
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 10:22
To: masinter.pa
Subject: vote
Larry, I thought I sent these to you, so if it's a repeat, just
discard.
Also, I grouped these issues loosely (but I didn't check them after
I grouped them, so some issues could be misplaced). I thought that
voting in alphabetic order was very painful and we didn't give enough
time to some issues just because of their position in the alphabet.
These votes don't represent the vote of DEC. Also, I gave more thought
to the no votes than to the yes ones.
kc
Single function change: My vote:
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION y
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE y
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY y
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES y
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR y
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE y
DESCRIBE-INTERACTIVE:NO n
EQUAL-STRUCTURE:STATUS-QUO y
EXPT-RATIO:P.211 y
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN y
FORMAT-PRETTY-PRINT:YES y
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY y
LCM-NO-ARGUMENTS:1 y
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT y
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN y
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR y
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK y
ROOM-DEFAULT-ARGUMENT:NEW-VALUE y
SYMBOL-MACROLET-DECLARE:ALLOW y
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM y(1)
TAGBODY-CONTENTS:FORBID-EXTENSION y(1)
TAILP-NIL:T y
STEP-ENVIRONMENT:CURRENT y
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS n
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW y
Documentation clarification:
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION y
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM n
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS n
LISP-SYMBOL-REDEFINITION:DISALLOW y
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS y
SUBTYPEP-TOO-VAGUE:CLARIFY y
New functions:
DEFPACKAGE:ADDITION y
FUNCTION-COMPOSITION:NEW-FUNCTIONS n
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS n
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER n
LAMBDA-FORM:NEW-MACRO y
NTH-VALUE:ADD n
PACKAGE-DELETION:NEW-FUNCTION n
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS y(2)
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS n
Multiple function change:
ARGUMENTS-UNDERSPECIFIED:SPECIFY y
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY y
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD y
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER y
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL y
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE n(3)
RETURN-VALUES-UNSPECIFIED:SPECIFY y
TEST-NOT-IF-NOT:FLUSH-ALL n(3)
TEST-NOT-IF-NOT:FLUSH-TEST-NOT n(3)
Concept change:
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING y
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE y
DECLARATION-SCOPE:NO-HOISTING n
DECLARATION-SCOPE:LIMITED-HOISTING y
DECLARE-TYPE-FREE:ALLOW y
DOTTED-MACRO-FORMS:ALLOW y
EXIT-EXTENT:MINIMAL n
EXIT-EXTENT:MEDIUM n
FUNCTION-DEFINITION:FUNCTION-SOURCE y
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE y
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE n
HASH-TABLE-TESTS:ADD-EQUALP y
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE y
PACKAGE-CLUTTER:REDUCE y
PROCLAIM-LEXICAL:LG y
REST-LIST-ALLOCATION:NEWLY-ALLOCATED n
REST-LIST-ALLOCATION:MAY-SHARE n
REST-LIST-ALLOCATION:MUST-SHARE n
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS y
SETF-PLACES:ADD-SETF-FUNCTIONS n
SETF-SUB-METHODS:DELAYED-ACCESS-STORES y
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE y
(1) Need more clarification
(2) Two changes to proposal
(3) Should deprecate, not delete
New since last meeting:
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
REST-LIST-ALLOCATION:MAY-SHARE
REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
----- End Forwarded Messages -----
∂09-Jan-89 2341 CL-Cleanup-mailer Re: revised ISO discussion, revised DRAFT Gegenda and Subcommittee
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 23:41:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 23:40:26 PST
Date: 9 Jan 89 23:39 PST
From: masinter.pa@Xerox.COM
Subject: Re: revised ISO discussion, revised DRAFT Gegenda and Subcommittee
meetings
In-reply-to: Jan Zubkoff <jlz@lucid.com>'s message of Mon, 9 Jan 89
12:55:22 PST
To: Jan Zubkoff <jlz@lucid.com>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-234026-5560@Xerox>
We'll need a meeting room on Sunday-- late afternoon & evening. Will there
be a conference table and overhead projector? (You say "Guest Room 120").
The cleanup subcommittee meeting in DC was pretty big, but I've sofar only
heard from about 5 people this time.
∂10-Jan-89 0022 CL-Cleanup-mailer Issue: STREAM-ACCESS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 00:22:01 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 00:20:54 PST
Date: 10 Jan 89 00:20 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: STREAM-ACCESS (Version 2)
To: cl-cleanup@sail.stanford.edu
From: gz@spt.entity.com (Gail Zacharias)
Message-ID: <890110-002054-5595@Xerox>
The following paragraph from the description of OPEN-STREAM-P may
be misleading:
Streams are "open" until they have been closed with CLOSE, or, the
dynamic context of the creating/accessing macros of WITH-OUTPUT-TO-STRING,
WITH-OPEN-FILE, WITH-INPUT-FROM-STRING, WITH-OPEN-STREAM, have been
exited.
This may be taken to imply that the stream still exists (as a closed stream)
even after the dynamic extent of the WITH-xxx form is exited. Because these
stream objects have dynamic extent, they cannot be referenced in any way once
the WITH-xxx form exits. (They can't even be passed to OPEN-STREAM-P.) As a
practical example, the streams could be stack-consed, and future use could
cause crashes. The reference to exited WITH-xxx forms should be deleted, or
explanatory text should be added.
∂10-Jan-89 0024 CL-Cleanup-mailer Issue: STREAM-INFO (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 00:23:57 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 00:22:51 PST
Date: 10 Jan 89 00:22 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: STREAM-INFO (Version 6)
To: cl-cleanup@sail.stanford.edu
From: gz@spt.entity.com (Gail Zacharias)
Message-ID: <890110-002251-5597@Xerox>
Our opposition is based on the following points:
1) The defining property of WRITE-SPACE (that it must write exactly the number
of units given) is too restrictive. For example it may not be possible to
write whitespace to a stream in units smaller than a #\space character, if the
stream is associated with a (multi-font) ascii file or editor buffer (since
there may be no ascii character available that can be inserted in the
file/buffer to represent the whitespace). An implementation cannot simply
make the unit size equal to the width of a #\space character, because a
subsequent increase in font-size would again make the unit smaller than a
current #\space character.
2) The "additional properties" of PRINTED-WIDTH (i.e. 8 and 9, stating that
printed-widths are additive) are incompatible with some non-Roman scripts. For
example, in the Arabic language the glyphs used for characters are dependent
on the surrounding characters: in our Arabic implementation of Object Logo,
editing causes surrounding characters to change shape (and width) according to
their new context. The restrictions on PRINTED-WIDTH would make it difficult
to similarly incorporate the context-sensitive character portrayal features of
the Macintosh into our Common Lisp implementation.
3) In general we feel that the proposal is premature, given the current state
of i/o standards. We would prefer to wait for a complete solution (i.e. a
real graphics standard and extended characters set standard). We feel that
the current proposal is too specific and problematical for a proper place in
Common Lisp. For now, the desired features are probably best obtained via
implementation-specific functions.
∂10-Jan-89 0039 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 1)
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 10 Jan 89 00:39:28 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab02627; 10 Jan 89 0:57 EST
Received: from draper.com by RELAY.CS.NET id ac29577; 10 Jan 89 0:44 EST
Date: Tue, 10 Jan 89 00:16 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: REAL-NUMBER-TYPE (version 1)
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
re: Surely it must use the same mechanism that <= and < do...
OK, but is this really appropriate for type checking?
∂10-Jan-89 0039 CL-Cleanup-mailer Revised draft issue status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 00:39:32 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 00:38:20 PST
Date: 10 Jan 89 00:37 PST
From: masinter.pa@Xerox.COM
Subject: Revised draft issue status
To: cl-cleanup@sail.stanford.edu
Message-ID: <890110-003820-5607@Xerox>
There are a number of people/organizations that have indicated that they
have yet to send in their votes, so the "tally" isn't final.
While it would be asking too much to have final drafts of all cleanup
issues by next Monday, I'm hoping to print out, and bring copies of, the
Ready for release issues, and the expected amendments. So: if you can spare
some time, some new drafts of issues would help a lot.
I'll start the final alphabetical order pass tomorrow morning.
- - - - file arisia:cl-cleanup/issue-status
Voters:
1 David N Gray (TI)
2 Kim A. Barrett (IIM)
3 David Bartley (TI)
4 Sandra J Loosemore (Utah)
5 David Moon (Symbolics)
6 Dan Pierson (Encore)
7 Chris Perdue (Sun)
8 Aaron Larson (Honeywell)
9 Kathy Chapman (DEC)
10 Gail Zacharias (Apple)
In some cases I have changed a vote from Y to "I" (conditional) if the
comments said "Only if...." In a couple of cases I changed an "Abstain" to
"Conditional" where the associated comment indicated that as the intent.
ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 3, 2-Dec-88
Comments: reword to avoid "Status Quo" debate?
Status: needs new version
ALIST-NIL
Version 4, 1-Oct-88
Status: Withdrawn, recommend editorial
APPEND-ATOM
Synopsis: atom case of APPEND (left out of APPEND-DOTTED)
Version 1, 6-Dec-88
Status: Ready for release?
APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 1, 6-Jan-89
Comments: Fix *APPLYHOOK* too
Status: needs revision
ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Vote: 1y2y3y4y5y6y7y8y9y10y SPECIFY
Status: block vote
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Vote: 1y3y4y5y*6y7y8y9y10i UNIFY-UPGRADING
Comments: 10: if remove UPGRADED-ARRAY-ELEMENT-TYPE and
UPGRADED-COMPLEX-PART-TYPE?
Status: vote separate with amendment
BACKQUOTE-COMMA-ATSIGN-DOT
Synopsis: `(... ,@x) vs `(... . ,x). Same, or different?
Version 1, 22-Dec-88
Comments: Two proposals. Connection w/APPEND-DOTTED?
Status: needs new version
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, Released 5 Dec 88
Vote: 1y3y4y5y6y7y8y9y10y
Comments: 10: Would prefer to specify a value for CLOSE on closed streams.
What's the
point of leaving it undefined?
Status: block vote
α∂
CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 1, 6-Jan-89
Comments: Too many proposals, not all there.
COERCE-INCOMPLETE
Synopsis: Extend COERCE to handle default coercions? take an optional
FROM-TYPE?
Version 2, 21-Nov-88
Status: needs new version
COMPILE-AND-LOAD-VERBOSITY
Synopsis: how much typeout when :VERBOSE given to COMPILE and LOAD
Comment: is there an issue?
Status: not submitted?
COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88
Status: ready for release?
CONSTANT-SIDE-EFFECT
Synopsis: It is an error to do destructive operations on constants in code,
defconstant.
Version: not submitted
Status: => CONSTANT-MODIFICATION (compiler committee)
CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Vote: 1n2y3n4y5y6y7y8y9y10y TRANSITIVE
Status: block vote
DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Vote: 1n2n3n4y5n6y7i8y9n10y NO-HOISTING
Vote: 1y2n3y4n5y6i7y8i9y10n LIMITED-HOISTING
Comments: NO-HOISTING is too incompatible...could live with
LIMITED-HOISTING,
but unconvinced of the need for incompatible change. All problem
examples
easily solved by changing some variable names
6,8: support LIMITED-HOISTING if NO-HOISTING fails.
Either is better than nothing.
7: NO-HOISTING if cases hoisted by 2nd alternatives are treated as errors
and
LIMITED-HOISTING fails
Status: separate vote
DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Vote: 1n3y4y5y*6y7y8y9y10y DELETE-FTYPE-ABBREVIATION
Comments:
5: Moon is mildly opposed; gratuitously incompatible. Pitman favors
because benefit of making things regular outweighs costs
Status: block vote
DECLARE-TYPE-FREE
Version 8, 7-Dec-88, Released 9-Dec-88
Vote: 1a3y4y5n*6n7y8y9y10n ALLOW
Version 9, 2-Jan-89, Released 6-Jan-89
Comments: cleanup members voted
5,10: DECLARE-TYPE-FREE:LEXICAL(9, unreleased) Yes.
6: Y Version 9, ALLOW
N Version 9, LEXICAL
Status: separate voting on Version 9
DECLARE-TYPE-USER-DEFINED
Synopsis: allow (declare ((signed-byte 8) x y z)) for all type specifiers?
Status: Not submitted
DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Vote: 1y3y4a5y6y7y8i9y10a LIKE-ENCODE
Status: block vote
DEFINITION-DELETE
Synopsis: provide a way to get rid of structures, etc.
Status: not submitted
DEFMACRO-BODY-LEXICAL-ENVIRONMENT
Synopsis: Allow DEFMACRO at non-top-level to capture environment.
Status: not submitted to cleanup; in compiler committee
DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Vote: 1y3y4y5y*6y7i8y9y10y ADDITION
Comments: Spell out "at variance"; define semantics in terms of existing
package functions. Mail 6-Jan-89
7: If we allow time for more experimental usage of this before adopting it
8: believe that "should signal an error" should be "will signal an error"
Status: separate vote
DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Synopsis: defstruct accessors are proclaimed inline
Version 2, 7-Jan-89
Status: ready for release?
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 2, 21-Sep-88, Released 6 Oct 88
Vote: 1y2i3y4y5y6y7i8y9y10y ALLOW-KEY
Comments: 7: If the proposal is fixed as suggested by Kim Barrett
Version 3, 8-Jan-88
Status: ready for release?
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Vote: 1y2y3y4y5y6y7y8y9y10y YES
Status: block vote
DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 2, 7-Jan-89
Status: ready for release??
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 4, 31-Oct-88, Released 12-Dec-88
Vote: 1y2y3y4y5y6y7y8c9y10i DUPLICATES-ERROR
Comment: 8 Why string= on the names. Does that mean that foo:a and bar:a
cannot both be slots in the same structure? (check where accessors are
interned).
10: only DEFSTRUCT macro, not STRUCTURE-CLASS.
Status: vote separate
DELETE-FILE-NONEXISTENT
Version 1, 5-Oct-88
Comments: should just signal different errors?
Status: awaiting new version
DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Vote: 1n2a3n4n5y6n7n8a9y10a EXPLICITLY-VAGUE
Vote: 1y2y3y4y5i6y7y8y9n10a NO
Comments: 5: "Yes" for the NO option iff EXPLICITLY-VAGUE fails.
Status: separate vote
DOTTED-MACRO-FORMS
Vote: 1y2y3y4y5y6y7y8y9y10n ALLOW
Version 3, 15-Nov-88, Released 7-Dec-88
Status: block vote
DYNAMIC-EXTENT
Version 2, 15-Nov-88
Comments: Mail from Moon 2-Jan-89 outlines good solution
Status: need new proposal writeup
ELIMINATE-FORCED-CONSING
Synopsis: Add :RECYCLE or :MODIFY keyword arguments to sequence,
list & string functions where such arguments are useful.
Version 3, 31-Aug-88
Status: Need volunteer to pursue
ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
value in consistent format across implementations. This makes
them virtually useless. I would like to constrain the values
enough so that implementors knew what to provide as return
values, and provide some examples of intended uses."
Status: need volunteer to submit
EQUAL-STRUCTURE
Version 5, 1-Oct-88, Released 8 Oct 88
Vote: 1y2i3y4a5i*6y7y8y9y10a STATUS-QUO
Comments: Errors in EQUALP summary. EQUALP on hash-tables?
Status: need new version
ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88
Status: separate vote
EXIT-EXTENT
Summary: What happens with non-local exits out of UNWIND-PROTECT cleanup
clauses?
Version 5, 12-Dec-88, Released 12-Dec-88
Vote: 1a2n3a4n5n*6c7n8n9n10n MINIMAL
Vote: 1a2i3y4y5n*6c7y8y9n10y MEDIUM
Version 6, 8-Jan-89
Status: ready for release?
EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Vote: 1y2y4y5y6y7y8y9y10y P.211
Status: block vote
FILE-LENGTH-PATHNAME
Comments: Some people didn't seem to think
this was appropriate. No one seemed very interested in writing it up.
Status: not submitted
FILE-WRITE-DATE-IF-NOT-EXISTS
Synopsis: What does FILE-WRITE-DATE do if no such file?
Version: no proposal
Status: => non-existant "error signalling" committee
FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Vote: 1n2n3n4i5y6y7n8n9y10i TIGHTEN-DEFINITION
Vote: 1y2n3y4y5n6a7n8n9n10y TIGHTEN-FIXNUM-TOSS-BIGNUM
Comments: TOSS-FIXNUM-TOSS-BIGNUM
4, 10: TIGHTEN-DEFINITION if TIGHTEN-FIXNUM-TOSS-BIGNUM is voted down
I don't think either proposal really addresses the problem adequately
doesn't do much for anyone & will break some implementations.
8: BIGNUM not useful, but there are other non useful aspects; changing
requires better justification.
Status: separate vote
FOLLOW-SYNONYM-STREAM
Status: Not Submitted; lost in STREAM-ACCESS
FORMAT-E-EXPONENT-SIGN
Vote: 1y2y3y4a5y6y7y9y10a FORCE-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: block vote
FORMAT-NEGATIVE-PARAMETERS
Synopsis: What does FORMAT do when it gets negative numbers for count?
Version: No proposal
Comment: KMP will incorporate in the list-of-signals part of the signal
proposal
Status: need volunteer
FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Vote: 1y2y3y4y5y6y7y9y10y YES
Comments: remaining questions:
- Is PRINT-OBJECT used to print things of type FLOAT in any cases
where ~$, ~E, ~F, or ~G is used?
- Can users write any methods (including :AROUND, :BEFORE, etc) for
PRINT-OBJECT on type FLOAT?
If Yes and Yes, it matters whether any of those format ops bind
*PRINT-BASE* in order to achieve the effect prescribed by CLtL of
always printing floats in base 10. If the answer to either of those
questions is "No", then it doesn't matter.
Status: separate vote (amend to No and No?)
FORMAT-ROUNDING
Synopsis: specify that ~F rounds up
Version 1, 5-Oct-88
Comments: we don't like the proposal
recommend #+IEEE-FLOATING-POINT => round-to-nearest?
Status: withdrawn?
FUNCTION-ARGUMENT-LIST
Synopsis: want way to get argument list
Status: not submitted
FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88
Status: need new version
FUNCTION-COMPOSITION
Synopsis: Add new functions for composing function values
Version 4, 12 Dec 88, Released 12 Dec 88
Vote: 1n2n3n4n5y*6a7n8n9n10a NEW-FUNCTIONS
Vote: 1n2y3n4y5i*6y7i8n9n10i COMPLEMENT-AND-ALWAYS
Comments: fix Barry Margolin's complaint about the degenerate case of
COMPOSE
6: We would vote "Yes" for COMPLEMENT-AND-ALWAYS iff NEW-FUNCTIONS fails.
7,10: If a name better than "ALWAYS" can be found,
or if only COMPLEMENT were in the proposal
Amend ALWAYS => CONSTANTLY?
8: error in the proposal, the example for find-if specifies AND and
DISJOIN to be equivalent
Status: separate vote (w/amendment(s))
FUNCTION-DEFINITION
Version 2, 09-Dec-88, Released 9 Dec 88
Vote: 1y3y4y5y6y7y8a9y10a FUNCTION-SOURCE
Status: block vote
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Vote: 1y2y3y4y5y6y7y8y9y10y RESTRICTIVE
Status: block vote
FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Vote: 1y2n3y4a5y*6y7y8na9n10n USE-ACTUAL-ARGUMENT-TYPE
Status: block vote?
GC-MESSAGES
Synopsis: What about unsolicited GC messages?
Version 2, 14-Nov-88
Status: editorial UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS?
GET-MACRO-CHARACTER-DISPATCHING
Synopsis: What does GET-MACRO-CHARACTER return for dispatching macros?
Status: not submitted
GET-MACRO-CHARACTER-READTABLE
Vote: 1y3y4y5y*6y7y8y9y10y NIL-STANDARD
Version 2, 8 Dec 88, Released 8 Dec 88
Comments: test case says GET-DISPATCH-MACRO-CHARACTER returns EQ
functions; not required. Fix test case.
Status: separate vote (with amendment)
HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88
status: awaiting new version
HASH-TABLE-GC
Synopsis: allow hash tables with GCable keys
Status: no proposal
HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Vote: 1a3a4n5y*6y7y8a9n10n ADD-WITH-WRAPPER
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
10: should be functions
Status: separate vote (with amendment)
HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal
HASH-TABLE-STABILITY
Vote: 1a2y3y4c5n*6a7n8c9?10c KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88, Released 12 Dec 88
Comments: is this necessary? I won't oppose if others think it's important.
Agree with "additional comment"
Not at this time. No time to understand.
8: Check SXHASH, I thought it was supposed to work accross different
invocations of lisp. This appears to not be the case according to the
proposal. Since the proposal really isn't changing the language (I hope),
then it is really only a clarification of existing status, but I'm not sure
I understand the issue any more now than before I read it.
10: As best we can tell, all this proposal says is that it is an error
to
destructively modify elements of equal hash tables but ok to do so for eq
hash tables. We would support a simpler proposal stating this.
Status: separate vote?
HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 8 8
Vote: 1y3y4n5y*6y7y8y9y10y ADD-EQUALP
Comments: "We would really like to see = hash tables, too."
Status: block vote
IEEE-ATAN-BRANCH-CUT
Version 1, 13-Dec-88
Status: ready for release?
IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Vote: 1y2y3y4n5y6y7i8i9y10y SELECT-ONLY
Comments: 7, 8: "Yes" if DEFPACKAGE
If we allow time for more experimental use of DEFPACKAGE before
adopting this.
Status: block vote
IN-SYNTAX
Synopsis: like IN-PACKAGE but for readtables
Version 1, 21-Oct-88
Comments: too narrowly focused?
Status: needs new version
INPUT-STREAM-P-CLOSED
Synopsis: What do INPUT-STREAM-P and OUTPUT-STREAM-P do on closed streams?
Status: not submitted
INPUT-STREAM-P-EXAMPLE
Synopsis: (input-stream-p (make-broadcast-stream)) is NIL
Version 1, 26-Oct-88
Status: ready for release?
LAMBDA-FORM:NEW-MACRO
Vote: 1y3y4n5y6a7n8a9y10y
Version 4, 22-Nov-88, Released 8-Dec-88
Comments: 10 New special form would be even better.
Status: separate vote
LAMBDA-LIST-DUPLICATES
Status: withdrawn
LCM-NO-ARGUMENTS
Vote: 1y3y4y5y6y7y8y9y10y [Returns] 1
Version 1, 17 Oct 88, Released 8 Dec 88
Status: block vote
LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION
Synopsis: should LEAST-POSITIVE- and MOST-POSITIVE-XXX-FLOAT
numbers include denormalized ones in those implementations
that admit them?
Status: Not yet submitted
LET-TOP-LEVEL
Synopsis: What's top level?
Status: => clcompiler
LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88
Status: ready for release?
LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Vote: 1y3y4y5i6y7n8y9y10y DISALLOW
Comments: Don't like (DEFVAR CAR ...) example
LIST-TYPE-SPECIFIER
Synopsis: add a type specifier (LIST NUMBER)
Version 1, 28 Jun 88
Status: withdrawn
LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled
files
Version 1, 2-Jan-89
Status: need new version?
LOAD-TIME-EVAL
Synopsis: #, semantics not in read macro
Status: => clcompiler
LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Comments: same arguments as REQUIRE-PATHNAME-DEFAULTS?
Status: not submitted
MAKE-CONCATENATED-STREAM-EXAMPLE
Synopsis: (read (make-concatenated-stream (make-string-input-stream "1")
(make-string-input-stream "2"))) => 12?
Version 1, 26-Oct-88
Status: withdrawn, no issue (bug report to one implementation)
MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Vote: 1y2n3y4n5n*6y7n8y9y10n IMPLEMENTATION-DEPENDENT
Comments: Decreases portability, incompatible, special-case, has other ways
rationale incorrect, current practice incorrect
8: People writing portable code have more subtle problems to worry
about than the default :USE list anyhow
Status: separate vote
MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88
Comments: extend to take other keywords? MAKE-STRING should return
simple string always? Interaction with character proposal
Status: awaiting new version
MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Vote: 1y2y3y4y5y6y7y8y9y10y EXPLICITLY-VAGUE
NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Vote: 1a3n4n5y*6y7y8an9n10y ADD
Comments: OK, but of marginal value.
The proposal should clarify the treatment of n when it is out of range.
Any non-negative integer index values should be permitted.
NIL should result if the index argument is too large.
OUTPUT-STREAM-P-EXAMPLE
Synopsis: Clarify (output-stream-p (make-concatenated-stream)) is NIL?
Version 1, 26-Oct-88
Status: ready for release? Comments?
PACKAGE-CLUTTER
Vote: 1y2y3y4i5y6y7y8y9y10y REDUCE
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: stronger on properties; "implimentation"
Symbols that are special forms can have macros, be FBOUNDP
I don't see any need to restrict the use of internal symbols in
the CL package as property indicators
Stronger: implementation will not use any property names
which are on user-created packages (except by inheritance.)
Allow SETF of GET, GETF, and SYMBOL-PLIST?
Other properties also should be spelled out, as per Moon.
Status: separate vote with amendments
PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Vote: 1y3y4a5y6y7a8y9n10i NEW-FUNCTION
Comments: Minor glitches
10: Remove the description of "correctable" error to be signalled and
handled.
This sort of detailed error protocol is not specified for any other
function
and is not appropriate here
Status: separate vote with amendment
PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 1, 21-Oct-88
Comment: extend package accessors PACKAGE-NAME etc. to take strings too.
Status: need new version
PATHNAME-CANONICAL-TYPE
Status: => "pathname" committee?
PATHNAME-COMPONENT-CASE
Status: => "pathname" committee?
PATHNAME-LOGICAL
Status: => "pathname" committee?
PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous comments, all over the map
Status: need new version
PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Status: => "pathname" committee
PATHNAME-SYNTAX-ERROR-TIME
Status: => "pathname" committee
PATHNAME-TYPE-UNSPECIFIC
Vote: 1y3y4i5y6y7n9y10y NEW-TOKEN
Version 1 27-Jun-88, Released 7 Oct 88
Comments: ":UNSPECIFIC should be legal in all pathname fields, not just in
the
type field."
No Unix convention I know of requires this new concept. Perhaps a
couple of good examples would convince me.
Status: block vote? "amend" to be PATHNAME-UNSPECIFIC-COMPONENT?
PATHNAME-WILD
Status: => "pathname" committee
PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: How to deal with logical devices, :unspecific components, etc in
pathname functions
Comments: extension of PATHNAME-TYPE-UNSPECIFIC handled part
Status: ready for release?
PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM
Vote: 1y2y3y4n5y*6y7y8y9y10y FIRST-READ-CHAR
Comments: "All metastreams must now support PEEK-CHAR directly..."
conflict with the rationale for issue UNREAD-CHAR-AFTER-PEEK-CHAR,
which is to legitimize implementing PEEK-CHAR as READ-CHAR/UNREAD-CHAR?
Status: separate vote; amendment?
PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted
PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Vote: 1y3y4i5y6y7y8y9y10y USER-FUNCTIONS-WORK
Comments: This proposal would be OK if it specified that circularity only
had to be detected for objects that are contained in slots of the
structure, not random objects that are printed out by the structure
print function. Rationale: one way to handle circular printing is
to traverse the structure to detect circularities before
printing anything.
PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Vote: 1n3c4n5y*6y7n8i9y10n LG
Comments: change "Clarify" => "Define"
Good idea, but insufficient experience implementing&using.
Favor in principle, but want discussion to ensure we're talking about same
thing.
No fundamental complaint, but more experience needed before standard.
Define the status of unproclaimed free variables.
Presumably, they are an error; compilers should issue a warning.
I don't believe in separate "dynamic" environment, don't believe it
makes sense to support rapid access to Globals on stock hardware,
and don't understand what Scheme practices don't work in Common Lisp.
Perhaps I can be dissuaded about some or all of these opinions.
8: If it can be implemented easily then I'm for it.
PROCLAIM-SCOPE
Synopsis: PROCLAIM's scope can end at "file" boundaries?
Status: => clcompiler
PROMPT-FOR
Synopsis: Add function to ask user for a value
Status: awaiting resubmission
RANGE-OF-COUNT-KEYWORD
Version 3, 9-Oct-88, Released 14-Oct-88
Vote: 1y3y4y5y6y7y9y10y NIL-OR-INTEGER
Status: block vote
RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Vote: 1y2y3y4y5y6y7y8y9y10y INTEGER-AND-INTEGER-NIL
Status: block vote
READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Status: Not submitted
READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 2, 08-Jan-89
Comment: lengthy dissent from Le Brun
Status: ready for release?
REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 4, 29-Nov-88
Comments: want in-between version where sequence & N-set functions
are vague, but others are specified.
Status: needs new version
REMF-MULTIPLE
Synopsis: What does REMF do if it sees more than one INDICATOR?
Version 1, 26-Jan-88
Status: need new version
REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Vote: 1y2y3y4y5y6y7n8y9n*10y ELIMINATE
Comments: Deprecate instead. Do not remove from the Lisp package.
REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Vote: 1n2n3n4n5n6n7n8a9n10y NEWLY-ALLOCATED
Vote: 1y2y3y4y5y6y7y8a9n10n MAY-SHARE
Vote: 1n2n3n4n5n6n7n8a9n10n MUST-SHARE
Comments: Add a new kind of declaration?
8: All three stink. No idea what to do.
Status: vote separately
REST-LIST-EXTENT
Status: incorporated in issue DYNAMIC-EXTENT
RETURN-VALUES-UNSPECIFIED
Vote: 1y3y4y5y6y7y8y9y10y SPECIFY
Version 6, 9 Dec 88, Released 9-Dec-88
Status: block vote
ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Vote: 1y2y3y4a5y6y8a9y10n NEW-VALUE
Comments: "I liked KMP's suggestion of defining additional synonyms"
Status: block vote
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Version 6, 06-Oct-88
Comments: New version scales down rejected version
Status: ready for release?
SETF-FUNCTION-VS-MACRO
Version 3, 4-Nov-87, Released Nov 87
Vote: 1y3y4n5n*6y7i8i9y10n SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
SETF-PLACES
Version 1, 11-Nov-88, Released 9-Dec-88
Vote: 1n3n4i5n*6i7y8n9n10n SETF-PLACES:ADD-SETF-FUNCTIONS
Comments: premature to vote on this issue
want unified issue
7: If SETF-PLACES:ADD-SETF-FUNCTIONS fails.
other options?
8: SFVM:SF much better than before. What about
(defmacro (setf name) ?) Yes if nothing better
comes along.
SP:ASF would require code to have ugly #.
Status: vote separate, with amendments
SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 1, 5-Dec-88
Status: awaiting new version
SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: more careful definition of order of evaluation inside (SETF (GETF
...) ...)
Vote: 1a2y4y5y6y7n8y9y10y DELAYED-ACCESS-STORES
7: not "right" semantics? presentation needs work even if right.
Status: separate vote
SINGLE-FLOAT-NON-PORTABLE
Synopsis: remove SINGLE-FLOAT, DOUBLE-FLOAT a la FIXNUM?
Status: Not submitted
SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88
Status: Ready for release?
SPECIAL-VARIABLE-TEST
Synopsis: Add SPECIAL-VARIABLE-P?
Version 2, 31-May-88
Status: "On hold pending SYNTACTIC-ENVIRONMENT-ACCESS"
STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Vote: 2y3y4y5y6y7y8y9y10y DEFINED-CONTRACTS
Status: block vote
STANDARD-VALUE
Synopsis: user can say binding is "temporary"
Version 1, 21-Oct-88
Status: ready for release?
STEP-ENVIRONMENT
Vote: 1y2c3y4y5i6y7y8y9?10y CURRENT
Version 3, 20-Jun-88, Released 7 Oct 88
Comments: need clarification: compiled STEP only interprets
what would have already been interpreted if STEP wasn't there.
Status: separate vote with amendment
STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Vote: 1n3n4i5n*6y7y8i9y*10i ADD-TYPES-PREDICATES-ACCESSORS
Vote: 1n3n4?5y*6n7y8y10n ADD-TYPES-ACCESSORS
Vote: 1y3y4?5n*6n7y8a10n ADD-PREDICATES-ACCESSORS
Comments: Although requiring types instead of predicates forces the
implementation
of these streams as separate types, there is no obvious serious problem
which can result from that, and it leaves open the possibility of writing
methods on particular types -- if they are also classes -- are they? The
proposal should spell this out.
Having both the types and the predicates is unnecessary clutter.
Omitting the predicates makes for less overhead with no lost
functionality.
8: TYPES-ACCESSORS, then TYPES-PREDICATES-ACCESSORS, then abstain
Status: separate vote with amendment T => "true"
9: two changes to proposal
STREAM-CAPABILITIES
Version 1, 7/5/88
Synopsis: SAME-SOURCE-P, SAME-DESTINATION-P, etc
Status: awaiting new version, from "pathname/file" committee?
STREAM-DEFINITION-BY-USER
Synopsis: Want user-definable stream types.
Status: not submitted
STREAM-ELEMENT-TYPE-EXAMPLES
Version 1, 26-Oct-88
Synopsis: clarify STREAM-ELEMENT-TYPE may return different values?
Status: editorial? Need new proposal?
STREAM-INFO
Version 6, 30-Nov-88, Released 9 dec 88
Vote: 1y3y4y5i*6y7y8y9?10n ONE-DIMENSIONAL-FUNCTIONS
Comments: 5: We vote "Yes" only if the name-changing amendment mentioned in
the mail passes.
Also, the writeup incorrectly states that Newline is not a standard
character;
Perhaps someone has confused "standard" with "graphic".
Change: LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
8: prefer amendment. Can NIL be returned?
7: complex proposal; maybe changes in detail after experience?
10: inappropriate (examples in mail)
Status: separate vote
SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Vote: 1y2y3y5y*6y7y10y CLARIFY
Comments: complicated; not sure
Status: block vote
SYMBOL-MACROFLET
Version 1, 30 Sep 88
Synopsis: Add SYMBOL-MACROFLET gives lexical function expansion
Status: need new version
SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Vote: 1y3y4i5y6y7y8y9y10y ALLOW
Comments: 4: Only if SYMBOL-MACROLET-SEMANTICS passes
Status: block vote
SYMBOL-MACROLET-SEMANTICS
Vote: 1y2y3y4a5y6y7y8y*9y*10y SPECIAL-FORM
Version 5, 30-Nov-88, Released 9 Dec 88
Comments: 9: need more clarification
Status: block vote
SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
=> clcompiler
TAGBODY-CONTENTS
Version 5, 9-Dec-88, Released 9 Dec 88
Vote: 1y3y4y5i6y7y8y9y10i FORBID-EXTENSION
Comments: "The term "data element" is too vague in paragraph 2 of the
proposal.
Our "Yes" vote is contingent on correcting this.
lmm changed mind.
10: We support forbidding extensions, but oppose allowing duplicate and
unreachable tags. Instead we would prefer clarifying that () is a form
and not a valid tag.
Status: separate vote (with amendment?)
TAIL-RECURSION-OPTIMIZATION
Version 2
Status: => cl-compiler?
TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Vote: 1y2y3y4y5y*6y7a8y9y10y T
Comments: Current practice is wrong. Expand to LDIFF? Add :TEST?
The EQ -> EQL change at the last minute means this is not Genera current
practice, contrary to the current practice section.
Status: separate vote
TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Vote: 1n3n4y5y*6a7n*8na9n*10y FLUSH-ALL
Vote: 1n3n4i5y*6a7y8na9n*10y FLUSH-TEST-NOT
Comments: Unnecessary incompatible change
4: Flushing some is better than not flushing all
5: mostly happy with either,slight preference to FLUSH-ALL.
"Yes" contingent on:
- changing "remove" to "deprecate", and coming up with a
suitable policy for deprecation which allows a comfortable
transition from current practice.
- either of the FUNCTION-COMPOSITION proposals passing.
7: Perhaps deprecate these instead. They need to remain in
the LISP package. The functionality of REMOVE-IF-NOT is needed,
perhaps use the name KEEP-IF.
9: deprecate
Status: separate vote
THE-AMBIGUITY
Version 1, 21-Oct-88
Comments: typo, sense wrong
Status: ready for release with amendment
TRACE-ERROR
Synopsis: TRACE should signal errors if it doesn't understand
Version 1, 20-Jun-88
Comments: is this a cleanup?
Status: ready for release?
TRACE-FUNCTION-ONLY
Synopsis: extend TRACE to handle other specs
Comment: we don't like it
Status: withdrawn
TRUENAME-SYNTAX-ONLY
Version 1, 12-Sep-88
Synopsis: when does TRUENAME perform checking?
Comments: other options? leave more vague? Other questions?
Status: need new version => "pathname" committee
TYPE-OF-UNDERCONSTRAINED
Vote: 1y2c3y4y5i6y7i8y9n10y ADD-CONSTRAINTS
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: some "bugs" in the proposal
5: "Our "Yes" vote is contingent on the following issues being addressed:
- RANDOM-STATE should be added to the list of built-in types.
- (subtypep (type-of x) (class-of x)) => T T for all x, seems to have
been intended but is not actually said. It should be added.
- The implementation recommendation in the discussion about returning
only portable type specifiers should be discarded.
- Shouldn't this refer to classes with proper names rather than just
ones with names?
7: If fix scope of quantifiers in (a)
Amend: for all x, for all bt
(when (built-in-type-p bt)
(when (typep x bt) (assert (subtypep (type-of x) bt)))).
Status: separate vote with amendment
TYPE-SPECIFIER-PREDICATE
Synopsis: "Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time."
Comments: discussion on common lisp mailing list.
Status: Not yet submitted
UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens when you call an undefined function, use
an unbound variable?
Version 1, 29-Nov-88
Status: ready for release?
UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Vote: 1y2y3y4y5y6y7y8y9y10y DONT-ALLOW
Status: block vote
UNWIND-PROTECT-NON-LOCAL-EXIT
Status: renamed to EXIT-EXTENT
VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Vote: 1y3y4y5y6y7y8n9y10y SYMMETRIZE
Comments: Error checking gained by disallowing (var) is more important to
me than symmetry. If anything (var) should be disallowed in all forms.
Status: block vote
WRITE-NEWLINE
Synopsis: Add a :NEWLINE keyword to WRITE
Version 1, 20-Oct-80
Comments: we don't like it
Status: withdrawn?
∂10-Jan-89 0149 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Jan 89 01:49:51 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01844g; Tue, 10 Jan 89 01:45:37 PST
Received: by bhopal id AA12606g; Tue, 10 Jan 89 01:47:53 PST
Date: Tue, 10 Jan 89 01:47:53 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901100947.AA12606@bhopal>
To: masinter.pa@Xerox.COM
Cc: IIM%ECLA@ECLC.USC.EDU, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 9 Jan 89 22:30 PST <890109-223056-5490@Xerox>
Subject: Issue: EQUAL-STRUCTURE (Version 5)
re: What is current practice in this area? What does EQUALP do in current
implementations on hash tables?
Lucid does something slightly wrong -- it descends component-wise using
an arbitrary indexing into each table. Thus it will be guaranteed to
get the wrong answer when the two tables contain the same data, but
were built up in differing orders such that the collision chains
are different [for any reasonable hashing implementation, you can
find an example of this].
It would be about a 5-minute job to fix it (i.e. to do the coding
for a fix, and minimal checkout). Of course this would require a QA
step for any commercial implementation, so that is the painful part.
I suspect the reason we have never fixed it is that:
-- So far, no customer/user has discovered the anomaly; or at least,
no one is aware of a bug in their program due to this anomaly.
-- Neither CLtL, nor Guy's "Clarifications" of 6-Dec-85, nor current
Cl-cleanup discussions, have brought a sense of inevitability to
the issue yet.
In short, I don't recommend Lucid's current practice or experience as
having any informational value here.
-- JonL --
∂10-Jan-89 0413 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Jan 89 04:13:09 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01880g; Tue, 10 Jan 89 04:09:02 PST
Received: by bhopal id AA12797g; Tue, 10 Jan 89 04:11:19 PST
Date: Tue, 10 Jan 89 04:11:19 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901101211.AA12797@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@Sail.Stanford.Edu, masinter.pa@Xerox.COM
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 11:57 PST <890106-115801-255@Xerox>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
re: 'Eliminate the distinction between types "for declaration" and "for
discrimination".'
In the initial proposal, I thought it was clear from the context that
this applied only to ARRAY type specifiers (and the later added COMPLEX
specifiers); but if someone was confused about it, it wouldn't hurt to
make it explicit.
re: Stylisticly, this can be accomplished quickly if a bit awkwardly, by saying
"The proposal is written using the following two functions, although these
functions are not added to the standard." [UPGRADE-ARRAY-ELEMENT-TYPE ...]
The whole point of proposing these two functions is the acknowledgement that
every implementation must have them under one name or the other. So why
not use the same name, so that user code can access them? The alternative
of a portable definition is not functinoally equivalent, since it conses.
-- JonL --
∂10-Jan-89 0624 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89 06:24:17 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 518333; Tue 10-Jan-89 09:22:23 EST
Date: Tue, 10 Jan 89 09:22 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 2)
To: MLB@WHITE.SWW.Symbolics.COM
cc: Cassels@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@Sail.Stanford.EDU,
DySak@STONY-BROOK.SCRC.Symbolics.COM,
JGA@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM,
rwg@WHITE.SWW.Symbolics.COM
In-Reply-To: <19890110015752.6.MLB@METAL-FLAKE.SWW.Symbolics.COM>
Message-ID: <890110092213.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Would your concerns be addressed if CL adopted REAL with the provision
that RATIONAL and FLOAT might not be an exhaustive partition of real?
In that way, an IRRATIONAL type (and/or perhaps others) could be added
by implementations wanting to.
Your remarks about the possibility of an irrational amount to a
strengthening of the need for REAL, since it points up the fact that
anyone now using the indicated OR type is setting themselves up to be
confused by other number types which come along (either in future CL's
or in some particular present-day CL sub-dialect) which actually might
be perfectly ok for their application. If they could say REAL, they
could permit these unexpected types in a natural way.
The practical impact on CL programmers would be that they were advised
to do:
(TYPECASE number
(REAL
(ETYPECASE number
(FLOAT ...)
(RATIONAL ...)))
...)
rather than:
(TYPECASE number
(REAL
(TYPECASE number
(FLOAT ...)
(OTHERWISE ;presumably RATIONAL
...)))
...)
By the way, I'm surprised by your reaction partly because there are already
other things in CL (most notably a definition of COMPLEX such that RATIONAL
is not a subtype, and such that the real and imaginary parts must be of the
same machine representation) which are not true to mathematics already.
Given this, I'm surprised you even care whether the rest of the type system
corresponds. I would assume that any serious mathematics would want to be
reconstructed atop CL rather than rely on its native partitionings, which
already seem off base, as (for example) Macsyma has done.
It seems clear to me that CL is not going to provide true representations
of mathematics. The real question is, should CL be permitted to provide
approximate representations? I think the answer is yes. I keep coming back
to the following analogy in my mind: CL's type system is to a mathematical
type system as floats are to reals in math ... some may legitimately say
the two have nothing to do with each other, yet you can still get useful
work done even with the crude approximations.
Indeed, the more you let the approximation -be- an approximation, the
more work you're likely to get done. I think programmers don't mind making
exceptions for things Lisp might really do, but I also think the more you
force the programmer into thinking about abstract concepts which in fact
do not exist in any implementation, the more the programmer can feel
you're just wasting his time and the less likely he's going to be to use
this language the next time. If CL really -had- irrationals, we would modify
the definitions of things to suit irrationals. But if CL is not going to
have irrationals, there's a fine line between the extensibility issues
you raise and the practical day-to-day overhead of a programmer who may
wonder if by the time it comes to extend the language he won't be programming
in some other language anyway...
So I guess I'm willing to see a compromise, stating that RATIONAL and FLOAT
are not an exhaustive partition of REAL, but I'm observing that that
compromise is not without cost.
Beyond that, the issue is simple: programmers want a word to use. REAL is
the word which is used by other languages. We can avoid REAL if there is a
strong reason to do so, but we should then have some other word.
Your critical suggestions are interesting and somewhat helpful, but if you
now make a constructive suggestion -- ``how should we proceed?'' -- it
might be more helpful. My reading is that people are not yet so wedded to
this proposal that they wouldn't be willing to change if someone made a
reasonable, concrete, alternative proposal. What we most lack is time.
∂10-Jan-89 0733 CL-Cleanup-mailer Issue: STREAM-INFO (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89 07:33:07 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 518365; Tue 10-Jan-89 10:31:24 EST
Date: Tue, 10 Jan 89 10:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 6)
To: gz@spt.entity.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890110-002251-5597@Xerox>
Message-ID: <890110103117.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
From: gz@spt.entity.com (Gail Zacharias)
Date: 10 Jan 89 00:22 PST
... it may not be possible to write whitespace to a stream in units
smaller than a #\space character, if the stream is associated with a
(multi-font) ascii file or editor buffer (since there may be no ascii
character available that can be inserted in the file/buffer to
represent the whitespace). ...
This is a good point. I think the wording should be loosened to indicate
the obvious -- that an implementation should not be branded non-conforming
if it does the closest approximation to the right thing for the stream,
font, device, operating system, etc. that it is dealing with.
To the extent that this hook is primarily to support portable pretty
printers My belief is that people would quickly learn to use a fixed
width font for pretty printed code if the approximate behavior bothered
them, but those who insisted on using bold would be happier with an
approximation to pretty printing than none at all. Of course, nothing
prevents a particular vendor in this mess from providing a proprietary
pretty printer which deals better -- and I'm sure people would use it --
but the idea is to provide a means to save a lot of vendors that work.
How about if the function returned information saying whether it
believed it had correctly achieved its stated goal?
... In general we feel that the proposal is premature, given the
current state of i/o standards. ...
This is the sort of reasoning that led us to not have a way to clear
the screen in portable code under CLtL. [A situation we should probably
rectify even now...]
My belief is that the needs of the Common Lisp community are better
served by a slightly faulty implementation that tries to win as much
as it can than by no implementation.
If and when a better solution exists (eg, some window system spec),
the window system spec can contain advice to its users that they should
no longer use the clumsy primitives provided by ANSI Common Lisp.
∂10-Jan-89 0906 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 10 Jan 89 09:06:18 PST
Received: by ti.com id AA04983; Tue, 10 Jan 89 11:06:01 CST
Received: from Kelvin by tilde id AA10141; Tue, 10 Jan 89 10:54:55 CST
Message-Id: <2809443435-15097074@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 10 Jan 89 10:57:15 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>, masinter.pa@Xerox.COM
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-Reply-To: Msg of Wed, 4 Jan 89 01:39:19 PST from Jon L White <jonl@lucid.com>
> re: I'd like to see the writeup make it clear that the following is subsumed;
> . . .
> Proposal SPECIAL-TYPE-SHADOWING:CLARIFY
...
> I don't think it is subsumed. The various versions of DECLARE-TYPE-FREE
> permitted an inner nested declaration to be merely overlapping with
> an outer declaration; but Gray's proposal requires local (read: "inner")
> declarations to be subtypes of the global proclamations (read: "outter")
I don't think it is subsumed, but not for that reason. The treatment
of overlapping declarations is intended to be consistent; but
DECLARE-TYPE-FREE still makes no mention of type proclamations. Also,
the proposal section of DECLARE-TYPE-FREE seems to have lost a clear
definition of the semantics of overlapping declarations, although it is
clarified in the discussion section. The proposal needs to explicitly
say that nested type declarations combine rather than being shadowed.
∂10-Jan-89 0948 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 2)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 10 Jan 89 09:46:31 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06415; 10 Jan 89 17:39 GMT
Date: Tue, 10 Jan 89 17:41:48 GMT
Message-Id: <14751.8901101741@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: REAL-NUMBER-TYPE (version 2)
To: Marc Le Brun <MLB%white.sww.symbolics.com@NSS.Cs.Ucl.AC.UK>
Cc: CL-Cleanup@sail.stanford.edu
There are dangers in introducing the term REAL. It encourages the
widespread confusion between a computer type, REAL, which of necessity
denotes a countable class of symbols, with the mathematical object (which
I'll call R), which is non-denumerable.
Don't we already have such problems with COMPLEX?
Hummm, maybe you're right, and we shouldn't have REAL. Common Lisp
COMPLEX seems to mean the representastion rather than the set, so that
(subtypep 'rational 'complex) => NIL, T
So adding REAL seems to imply further revisions.
∂10-Jan-89 1019 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 10:19:41 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 10 Jan 89 13:11:50 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 10 Jan 89 13:16:52 EST
Date: Tue, 10 Jan 89 13:17 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST
To: cl-cleanup@sail.stanford.edu
Message-Id: <19890110181742.7.BARMAR@OCCAM.THINK.COM>
Issue: COPY-SYMBOL-COPY-PLIST
References: COPY-SYMBOL (p 169), COPY-LIST (p 268), COPY-TREE (p
269).
Category: CLARIFICATION
Edit history: 10-Jan-89, Version 1 by Margolin
Problem Description:
The description of COPY-SYMBOL, where the COPY-PROPS optional argument
is non-NIL, says that a copy of the property list is used as the new
symbol's property list. However, there are several ways in which a list
may be copied, most notably COPY-LIST and COPY-TREE, and the description
doesn't say which mechanism should be used.
Proposal (COPY-SYMBOL-COPY-PLIST:COPY-LIST)
Clarify that when COPY-SYMBOL copies the property list of the symbol, it
is as if (COPY-LIST (SYMBOL-PLIST sym)) were used as the new symbol's
property list.
Rationale:
COPY-LIST is the simplest list-copying primitive. The result of this
copy is that GET returns EQL results for the two symbols until one of
the property lists is altered, but altering either of the property lists
doesn't affect the other. This is current practice in the
implementations I tested, and probably what most users assume.
Current Practice:
Symbolics Genera and Sun Common Lisp currently implement this. I
suspect most others do, too.
Cost to Implementors:
Little or none.
Cost to Users:
None unless they've been assuming some other type of copy.
Benefits:
Less ambiguity.
Aesthetics:
Well, I like it.
∂10-Jan-89 1042 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89 10:42:17 PST
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 518546; 10 Jan 89 13:40:31 EST
Date: Tue, 10 Jan 89 13:40 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 2)
To: MLB@WHITE.SWW.Symbolics.COM, Cassels@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@Sail.Stanford.EDU, DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM, rwg@WHITE.SWW.Symbolics.COM
In-Reply-To: <19890110015752.6.MLB@METAL-FLAKE.SWW.Symbolics.COM>
Message-ID: <19890110184025.0.CASSELS@GROUSE.SCRC.Symbolics.COM>
Date: Mon, 9 Jan 89 17:57 PST
From: Marc Le Brun <MLB@WHITE.SWW.Symbolics.COM>
Date: Sun, 8 Jan 89 11:29 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Issue: REAL-NUMBER-TYPE
[...]
I apologize for the size of this response, but since this is sort of a "dissenting opinion" I
felt it would be good to document the arguments as carefully as I could.
There are dangers in introducing the term REAL. It encourages the widespread confusion
between a computer type, REAL, which of necessity denotes a countable class of symbols, with
the mathematical object (which I'll call R), which is non-denumerable. This identification of
incommensurables has many unfortunate consequences, including ambiguous and inconsistent use
of "intuitive" models. Further, members of these sets which are commonly identified with
eachother (ie real numbers and their computer images) often have incompatible semantics.
The original Common Lisp specification did the world a service by eliminating this source of
potential confusion. If the term is to be reintroduced for pragmatic reasons, then it should
at least done very carefully, so as not to result in further propagation, even amplification,
of these problems. It doesn't seem either responsible or forward-looking to gloss over these
difficult issues.
Add a standard type specifier
(REAL low high)
which means
(OR (RATIONAL low high) (FLOAT low high))
The Discussion section below implies that future extensions should be considered here.
Suppose an implementation introduces new types which model members of R but which do not
satisfy this predicate. (For example, quadratic fields, or symbols denoting rational
multiples of (mathematical) pi, say). Is the implementation allowed to extend the type REAL
or not? I'd vote to allow extension, but in any case this should be stated. (Further, must
it so extend it?)
CL currently does not try to carefully restrict extensions to itself.
Overall, this is probably good although there are reasons to want a
strict language, too. I think that the best we can do for any given
point in the development of the language is to describe what it *is* and
pick the sharpest possible terms for all the concepts, so that we don't
*preclude* interesting extensions.
As with other such type specifiers, define that if the low and high
are omitted, the atomic specifier REAL may be used.
Clarify that NUMBER is equivalent to (OR REAL COMPLEX).
... in the existing language.
Suppose an implementation introduces new types which could considered numeric but which do not
satisfy this predicate. (For example, quaternions, as mentioned in the Discussion). Is the
implementation allowed to extend the type NUMBER or not? I'd vote to allow extension, but in
any case this should be stated. (Further, must it so extend it?)
Again, I don't think we should try to guess what extensions might be
interesting. An extension should be made "the right way."
Make REAL a built-in CLOS class.
Proposal (REAL-NUMBER-TYPE:REALP):
Add a specific data type predicate REALP which tests for membership in
this type. [By analogy with NUMBERP.]
Test Case:
If a programmer wishes to test for "a number between 1 and 10", the
only current CL types would be '(or (rational 1 10) (float 1 10)) or
something like '(and numberp (not complexp) (satisfies range-1-10))
with (defun range-1-10 (real) (<= 1 real 10)). Both of these are
likely less efficient, and certainly less expressive than '(real 1 10).
Rationale:
Mathematics has a name for (OR RATIONAL FLOAT) -- it is "real".
No.
1. As noted above R contains many "useful" elements (eg surds, mathematical pi or e) which can
have discrete symbolic representations but whose behavior is not accurately modeled by any
REAL element.
2. Under many circumstances the semantics of "typical" elements of REAL are quite distinct
from the elements of R with which they are commonly identified, leading to a variety of
situational interpretations as "intervals", "fuzzy numbers", etc which clearly do not belong
to the theory of R.
3. Conversely operations on elements of R conform to a semantics of "infinite precision"
obviously unattainable by REALs.
4. REAL also may contain specific entities (such as -0.0) not in R.
5. Because of finite range limitations REAL further does not consistently "cover" R.
Sometimes this is dealt with as an error, sometimes with the introduction of non-analytic
semantics (eg setting underflows to zero), sometimes by introducing non-standard entities
partially or wholly outside R (eg the various "infinities", or the IEEE "Not-A-Number"s which
(at least in Symbolics CL) paradoxically satisfy NUMBERP!).
6. Since there is no "floating canonicalization", the type REAL contains multiple distinct
images of certain elements of R (notably zero, many rationals, and many flonums which exist in
more than one so-called "precision").
This class is important because it is all the numbers which can be ordered.
Agreed that the ordering property of R is important. It might be possible to have CL so
define REAL specifically as some kind of maximal well-ordered set (though this might be
tricky, in order to exclude characters as potential numbers, for example).
(And, mathematically anyway, one might even ask for more rigor regarding the term "ordered",
considering, for example, Conway numbers. This would be a gratuitous comment except for IEEE
having already opened the Pandora's box of non-standard numbers.)
Throughout the "Numbers" chapter, the phrase "non-complex number" is used.
MAX, MIN, p. 198 "The arguments may be any non-complex numbers."
CIS p. 207 "The argument ... may be any non-complex number."
Presumably this is to be read as a proposal to substitute "real" for "non-complex number"?
Note that these restrictions are apparently motivated by different properties: in some cases
ordering, in others an aversion to imaginary algebra (eg the mystifying restrictions on CIS,
COMPLEX et al). Depending on the extension policy adopted that substitution might or might
not retain its validity under an extension (eg symbols for rational multiples of mathematical
pi aren't (OR RATIONAL FLOAT) but might be an acceptable, indeed useful, subdomain for CIS).
[...]
Benefits:
Mathematical clarity.
Arguable.
Ability to do CLOS method dispatch on the type.
[...]
Discussion:
The name "non-complex number" is incorrect because future
implementations may wish to include numerical types which are neither
complex nor real. [e.g. pure imaginary numbers or quaternions]
As noted above, the policy regarding possible extensions, either as future CL standards or
per-implementation, should be clarified in several respects.
As noted above, there should be no "policy" on future extensions.
The name "scalar" is incorrect because the mathematical concept of
scalar may indeed include complex numbers.
Fortran and Pascal use the name "real" to mean what CL calls
SINGLE-FLOAT. That should cause no significant problem, since a Lisp
program written using the type REAL will do mathematically what the
equivalent Fortran program would do. This is because Fortran's "real"
data-type is a subtype of the CL REAL type. The only differences
might be that the Lisp program could be less efficient and/or more
accurate.
This needs clarification. If by "equivalent Fortran program" is meant a FORTRAN program that
was specifically (heroically?) written to carefully model a CL program, then this begs the
question. If it means "a naive translation" between languages, then this is far from obvious
(eg a CL implementation might generate rationals, thereby maintain different information
through subsequent operations, and finally get results diverging significantly from the
FORTRAN program).
One could also easily imagine some careful conventional flonum-based numerical analysis being
thrown off by the introduction of a non-zero rational smaller than CL "epsilon", for example.
The assignation of "more accurate" is application-dependent and implementation-dependent.
Any program which depends in any significant way on range or precision
must *always* be translated carefully -- even when moving from one
Fortran implementation to another. Experts always need to know
*exactly* how a particular computation will be done, and will always
have to read reference manuals carefully.
A survey of several Fortran and Pascal books shows that the distinction
between INTEGER and REAL is that REAL numbers may have fractional
parts, while INTEGERs do not. Later discussions explain that REALs
cover a greater range. Much later discussions cover precision
considerations, over/underflow, etc. So the average Fortran or Pascal
programmer should be completely comfortable with the proposed Lisp
concept of REAL.
Agreed, the proposed type is an extension of what's commonly meant by the name REAL.
(Although there exist unusual systems where REALs are implemented by decimal rationals!)
While the "average programmer" may be comfortable, the differences between CL REALs and
conventional REALs and their implications should be carefully and thoroughly documented in the
standard (leaving aside the quagmire of confusion with regards to R).
We're not adamant about the name "real". We do believe strongly that
the concept should be a part of the language as a distinct named type.
Suggestions for a better name are welcome.
You can't seriously expect a language definition to "carefully and
thoroughly" document all the differences between all other uses of a
word and the use in that language. You are certainly right that a
"compatibility note" of the sort already in CLtL is warranted. A
distilled version of your comments here would be quite appropriate.
∂10-Jan-89 1042 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 5)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 10:42:31 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA07207; Tue, 10 Jan 89 10:44:11 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA26417; Tue, 10 Jan 89 10:40:43 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA13760; Tue, 10 Jan 89 10:41:42 PST
Date: Tue, 10 Jan 89 10:41:42 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901101841.AA13760@clam.sun.com>
To: cperdue@Sun.COM, masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-SUB-METHODS (Version 5)
Cc: cl-cleanup@sail.stanford.edu
> In your ballot, you said:
>
> This does not seem to be the "right" choice of semantics, and I
> believe that the presentation of the proposal needs substantial work
> even if it is "right".
>
> Can you help us? in what way is it wrong? what might be better? what
> cases are unclear that we need to clarify?
Right. I didn't feel I could do justice to this issue before the January
X3J13 meeting.
Perhaps these comments will be of some use:
Consider example 6.
(setq s (setq r (list 'a 1 'b 2 'c 3)))
(setf (getf r 'b) (progn (setq r nil) 6))
r ==> (b 6)
s ==> (a 1 b 2 c 3)
I find the SETF expression naturally maps to:
(setf r (put-plist r 'b (progn (setq r nil) 6)))
where put-plist is a destructive function on lists in the usual
Common Lisp style, where it must be used for its value.
With this expansion,
r ==> (a 1 b 6 c 3)
s ==> (a 1 b 6 c 3)
Perhaps I am wrong, but I think others will realize that they find
this more natural also.
Concerning the statement of the proposal, it seems to me that 3
half-page discussions -- one for CHAR-BIT, one for GETF, and one
for LDB and MASK-FIELD, is far too much to have to say about such
a fine point in the language.
∂10-Jan-89 1050 CL-Cleanup-mailer Issue: STREAM-INFO (Version 6)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 89 10:50:07 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA13470@EDDIE.MIT.EDU>; Tue, 10 Jan 89 13:48:01 EST
Received: by spt.entity.com (smail2.5); 10 Jan 89 12:58:22 EST (Tue)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Tue, 10 Jan 89 10:31 EST <890110103117.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 6)
Message-Id: <8901101258.AA10804@spt.entity.com>
Date: 10 Jan 89 12:58:22 EST (Tue)
From: gz@spt.entity.com (Gail Zacharias)
Date: Tue, 10 Jan 89 10:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
To the extent that this hook is primarily to support portable pretty
printers My belief is that people would quickly learn to use a fixed
width font for pretty printed code if the approximate behavior bothered
them, but those who insisted on using bold would be happier with an
approximation to pretty printing than none at all. Of course, nothing
prevents a particular vendor in this mess from providing a proprietary
pretty printer which deals better -- and I'm sure people would use it --
but the idea is to provide a means to save a lot of vendors that work.
Then vendors who wish to do so, and who find a model such as presented by this
proposal appropriate for their implementation, can provide the hooks as
implementation-dependent extensions. The simple fact is that this proposal is
not universally implementable as stated, and loosening the restrictions would
mean that you still cannot write a portable pretty printer, i.e. one that
works correctly in all conforming implementations.
A pretty printer which assumes fixed width fonts by default, but allows
customization in ways appropriate for the text display model used by specific
implementations, is a better solution to this problem than putting functions
in the standard which are already known to be inappropriate for some existing
display models. I don't think it's the responsibility of the standard to
provide hooks that give the illusion of portability to non-portable programs.
∂10-Jan-89 1101 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89 11:01:20 PST
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 518575; 10 Jan 89 13:59:30 EST
Date: Tue, 10 Jan 89 13:59 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 2)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, MLB@WHITE.SWW.Symbolics.COM
cc: Cassels@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@Sail.Stanford.EDU,
DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM, rwg@WHITE.SWW.Symbolics.COM
In-Reply-To: <890110092213.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890110185930.1.CASSELS@GROUSE.SCRC.Symbolics.COM>
Date: Tue, 10 Jan 89 09:22 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
[..]
Beyond that, the issue is simple: programmers want a word to use.
We could note here that the Symbolics Common Lisp system already has a
name for the concept, and that since users have sent bug reports about
how poorly it's implemented, they must find it useful. The way this
concept appears in SCL is embarrassingly wrong, so I've refrained from
mentioning it so far. But now's the time....
(NUMBER <low> <high>) is treated as equivalent to
(OR (RATIONAL <low> <high>) (FLOAT <low> <high>))
Through some implementational fluke, (NUMBER * *) is equivalent to
NUMBER. Thus #C(1 2) satisfies (NUMBER * *) but not
(NUMBER <IEEE minus infinity> <IEEE plus infinity>).
REAL is
the word which is used by other languages. We can avoid REAL if there is a
strong reason to do so, but we should then have some other word.
Right. The concept is demonstrably used and useful.
∂10-Jan-89 1429 CL-Cleanup-mailer Issue: STREAM-INFO (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89 14:28:55 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 518773; 10 Jan 89 17:26:38 EST
Date: Tue, 10 Jan 89 17:26 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 6)
To: gz@spt.entity.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: <8901101258.AA10804@spt.entity.com>
Message-ID: <890110172620.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 10 Jan 89 12:58:22 EST (Tue)
From: gz@spt.entity.com (Gail Zacharias)
...
Then vendors who wish to do so, and who find a model such as presented
by this proposal appropriate for their implementation, can provide the
hooks as implementation-dependent extensions.
In practice, vendors don't do this. They each think their own theory of how
to provide the hooks is best, each insisting that other vendors' views of
the world are wrong. In the absence of an external agency (like ANSI) to
force agreement, each feels entitled to disagree, believing it is right.
The advantage of a standard is that it enforces a little agreement.
The simple fact is that this proposal is
not universally implementable as stated, and loosening the restrictions would
mean that you still cannot write a portable pretty printer, i.e. one that
works correctly in all conforming implementations.
Technically, no, but for the universe of programmers we can reasonably
expect to sell to in the commercial community which ANSI influences, you
can do awfully good. If someone has a CL that supports Hebrew, let them
write their own pretty printer. I'd be surprised if they didn't plan to
do so anyway, so I doubt I'm asking them to do extra work.
On the other hand, experience shows that Dick Water's very interesting
pretty printer did not reach all the target audiences that would have liked
to have it because he didn't have the time to adapt it to everyone's
idiosyncratic view of thew world, and they didn't have enough time to
look over his code and realize how little work it would take to get it up
and running.
That's a real shame. This change comes to us from the CL user community
from Waters himself, who tried to use those hooks which you assert
everyone has, and who found it too much work. I think it's our obligation
to try to address his need in some way if we can.
A pretty printer which assumes fixed width fonts by default, but allows
customization in ways appropriate for the text display model used by specific
implementations, is a better solution to this problem than putting functions
in the standard which are already known to be inappropriate for some existing
display models. I don't think it's the responsibility of the standard to
provide hooks that give the illusion of portability to non-portable programs.
How about if we permit an ERROR-P argument which controls whether you signal
an error or just continue if you are in a variable width font and can't support
the indicated operation. That way you'd get the benefits of your supposed
improvement (which is that fixed-width fonts would work) and implementations
which supported variable width fonts and arbitrary addressing would not be
penalized. In a few years, we could take some polls and find out if people
were mostly willing to set ERROR-P to T and let their application fall on the
floor when it ran up against a hard problem, or if they were mostly willing
to set ERROR-P NIL, so that their application would do the best it could do
rather than just falling apart in an obviously difficult situation. This would
have no illusion of portability since in reading about the ERROR-P argument and
deciding what to set it to, it would be clear to the programmer how the behavior
might vary between implementations.
∂10-Jan-89 1441 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89 14:36:11 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 518783; Tue 10-Jan-89 17:33:14 EST
Date: Tue, 10 Jan 89 17:33 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST
To: barmar@Think.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <19890110181742.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <890110173307.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Tue, 10 Jan 89 13:17 EST
From: Barry Margolin <barmar@Think.COM>
...
Rationale:
COPY-LIST is the simplest list-copying primitive.
...
In my book it's the -only- list-copying primitive. COPY-TREE doesn't
copy lists, it copies trees. Abstractly, there is no relationship
between the two except for people who think it's a bug that
(MEMBER 'A '(B (A) C))
doesn't find A in the given list.
I don't think there's much issue here, but I'm happy to go along with it
if you think there is.
If we do proceed, I'd go so far as to say that Kathy might want to
document that wherever in plain text the phrase "copy the list" is used,
the equivalent of COPY-LIST is intended, that wherever in plain text the
phrase "copy the tree" is used, the equivalent of COPY-TREE is intended,
and that wherever in plain text the phrase "copy the alist" is used, the
equivalent of COPY-ALIST is intended. This would save us having 42 more
of these issues come up now that you've opened this particular box
marked "Pandora"...
∂10-Jan-89 1443 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 14:43:27 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 14:41:53 PST
Date: 10 Jan 89 14:41 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Tue, 10 Jan 89
04:11:19 PST
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, cl-cleanup@Sail.Stanford.Edu
Message-ID: <890110-144153-6753@Xerox>
Even though all implementations "must have some code" that does the
upgrading, the code need not be a Lisp function. For example, KCL might do
the upgrading in C, or an implementation might simply upgrade all array
element types to T.
There's a cost associated with adding functions to the LISP package,
including them in the documentation and specification beyond the cost of
requiring all implementations to write them -- the cost is in the overhead
of testing, documentation, user understanding, burden on implementation
model. The benefit of UPGRADE-ARRAY-ELEMENT-TYPE--namely, that it doesn't
CONS as much as the portable definition--seems very small and I don't think
it outweighs the cost.
∂10-Jan-89 1458 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89 14:58:47 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 518809; 10 Jan 89 17:55:48 EST
Date: Tue, 10 Jan 89 17:55 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
To: Masinter.PA@Xerox.COM
cc: JonL@Lucid.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890110-144153-6753@Xerox>
Message-ID: <890110175533.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Also, for any given application, you usually know what types you care
about, so you can write a special-purpose, non-consing version for
that purpose by pre-caching the results at load time. For trivial
extra cost, you can have a table incrementally updated only on the
first call to the portable function with a particular argument, so the
end effect is negligible consing even in the general case.
∂10-Jan-89 1506 CL-Cleanup-mailer revised ISO discussion, revised DRAFT Gegenda and Subcommittee
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:06:26 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02617g; Tue, 10 Jan 89 15:02:13 PST
Received: by challenger id AA01019g; Tue, 10 Jan 89 14:58:08 PST
Date: Tue, 10 Jan 89 14:58:08 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901102258.AA01019@challenger>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu, jlz@challenger
In-Reply-To: masinter.pa@Xerox.COM's message of 9 Jan 89 23:39 PST <890109-234026-5560@Xerox>
Subject: revised ISO discussion, revised DRAFT Gegenda and Subcommittee
meetings
Room 120 will be set up Sunday with an overhead. Larry, you'll have to ask
the front desk for the key. I've reserved it from 2:00 on.
---jan---
∂10-Jan-89 1508 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:07:58 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 15:04:53 PST
Date: 10 Jan 89 15:04 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-reply-to: David N Gray <Gray@DSG.csc.ti.com>'s message of Tue, 10 Jan 89
10:57:15 CST
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Jon L White <jonl@lucid.com>, masinter.pa@Xerox.COM,
CL-Cleanup@sail.stanford.edu
Message-ID: <890110-150453-6808@Xerox>
I don't think it is subsumed now either; I've left SPECIAL-TYPE-SHADOWING
as a separate issue.
∂10-Jan-89 1527 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:26:47 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 15:23:04 PST
Date: 10 Jan 89 15:22 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: STREAM-INFO (Version 6)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 10 Jan 89 17:26 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: gz@spt.entity.com, cl-cleanup@sail.stanford.edu
Message-ID: <890110-152304-6870@Xerox>
Maybe these belong in a category of "optional extensions", i.e., you either
provide them all or don't. We've avoided options so far, because we
couldn't see any good reason for providing them, but this seems like it
might be a good reason.
I'm of the mind, though, that streams for which this is not a good model
should behave exactly like the default implementation "fixed-width"
implementation: every graphic character is of width 1 and the line width
is 80.
I'd think that would be more appropriate for a Mac implementation where it
is possible to change the font after-the-fact than actually paying
attention to the "real" width.
∂10-Jan-89 1536 CL-Cleanup-mailer Re: New proposed issue APPEND-ATOM
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:36:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 15:35:10 PST
Date: 10 Jan 89 15:34 PST
From: masinter.pa@Xerox.COM
Subject: Re: New proposed issue APPEND-ATOM
In-reply-to: masinter.pa's message of 6 Dec 88 17:57 PST
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890110-153510-6915@Xerox>
I have apparently misplaced:
Guy Steele <gls@Think.COM>'s message of Tue, 6 Dec 88 14:29:22 EST
Subject: New proposed issue APPEND-ATOM
Do you have it?
If you find it, would you mail it to me?
∂10-Jan-89 1551 CL-Cleanup-mailer New proposed issue APPEND-ATOM
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:50:51 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 518869; Tue 10-Jan-89 18:48:25 EST
Return-path: <CL-Cleanup-mailer@SAIL.STANFORD.EDU>
Received: from SAIL.STANFORD.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 504032; 6 Dec 88 14:43:29 EST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Dec 88 11:32:31 PST
Received: from fafnir.think.com by Think.COM; Tue, 6 Dec 88 13:52:42 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 6 Dec 88 14:30:50 EST
Received: by verdi.think.com; Tue, 6 Dec 88 14:29:22 EST
Date: Tue, 6 Dec 88 14:29:22 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8812061929.AA12814@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: New proposed issue APPEND-ATOM
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Tue, 10 Jan 89 18:47 EST
Resent-Message-ID: <890110184752.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: APPEND-ATOM
References: APPEND (p268)
Issue APPEND-DOTTED
Category: CHANGE/CLARIFICATION
Edit history: 06-Dec-88 by Steele
Problem Description:
The issue APPEND-DOTTED, as passed by X3J13, contains a minor technical
flaw: it can be construed as leaving undefined the case where an argument
to APPEND other than the last is an atom. The relevant paragraph of that
issue proposal is:
In the degenerate case where there is no last cons (i.e., the argument is
NIL) in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument
is a non-list, the result of APPEND or NCONC can be a non-list.
Here is the nit: the use of "i.e." leads one to believe that the
only degenerate case defined is that where the argument is NIL.
I suspect that "e.g." was intended, so as to make all atomic objects
ignored in other than the last argument.
Proposal (APPEND-ATOM:IGNORE):
In the degenerate case where there is no last cons (i.e., the argument
is an atom) in any but the last list argument, clarify that the entire
argument is effectively ignored. Point out that in this situation, if
the last argument is a non-list, the result of APPEND or NCONC can be
a non-list.
Proposal (APPEND-ATOM:ERROR)
In the degenerate case where there is no last cons (i.e., the argument
is an atom) in any but the last list argument, clarify that a value of
NIL is treated as an empty list and therefore effectively ignored, and
any other atom is an error. Point out that in this situation, if the
last argument is a non-list, the result of APPEND or NCONC can be a
non-list.
Examples (APPEND-ATOM:DOTTED):
(APPEND '(a b) 'MOOSE '(c . d)) => (a b c . d) ;Proposed
(NCONC '(a b) 'MOUSSE '(c . d)) => (a b c . d) ;Proposed
(APPEND 'GUACAMOLE 17) => 17 ;Proposed
(NCONC 'SAUERKRAUT 17) => 17 ;Proposed
Under APPEND-ATOM:ERROR these cases would all be errors.
Rationale:
APPEND-ATOM:IGNORE makes a boundary case (a "zero-length dotted list")
consistent with other cases handled by the proposal APPEND-DOTTED:REPLACE.
APPEND-ATOM:ERROR would at least resolve a possible ambiguity.
Current Practice:
Lucid Lisp, KCL, and Symbolics Common Lisp all signal an error in both
interpreted and compiled code.
Cost to implementors:
Technically, the change for APPEND-ATOM:IGNORE should be relatively
small for those implementations which don't already implement it.
However, implementations which have microcoded APPEND or NCONC
incompatibly may find the small change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect only
NIL when SAFETY is 0. In this case, depending on implementation details,
requiring an ATOM check rather than a NULL check may slow things down.
Cost to users:
Each proposal is upward compatible.
Benefits:
Since dotted lists are allowed as a non-last argument, readers will
probably assume that the boundary case of a zero-length dotted list
(that is, an atom) also works, something that doesn't appear to be
guaranteed by a strict reading. Proposal APPEND-ATOM:IGNORE would
happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the language
will depend largely on how they view the relation between lists and dotted
lists. Those who view dotted lists as a special kind of list may feel
differently than those who view lists as a special kind of dotted list.
The downside of APPEND-ATOM:IGNORE is that APPEND is supposed to
operate on lists, and it is mildly offensive to let it accept atoms,
and worse yet to ignore them. Furthermore, a certain amount of useful
error checking may be lost.
Discussion:
Guy Steele supports proposal APPEND-ATOM:IGNORE, but with some qualms.
He raises it mainly because of the possibility that
APPEND-DOTTED:REPLACE was not worded exactly as intended.
∂10-Jan-89 1551 CL-Cleanup-mailer Re: New proposed issue APPEND-ATOM
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:51:15 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 518871; 10 Jan 89 18:49:30 EST
Return-path: <CL-Cleanup-mailer@SAIL.STANFORD.EDU>
Received: from SAIL.STANFORD.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 504326; 6 Dec 88 21:21:40 EST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Dec 88 18:08:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 DEC 88 17:58:06 PST
Date: 6 Dec 88 17:57 PST
From: masinter.pa@Xerox.COM
Subject: Re: New proposed issue APPEND-ATOM
In-reply-to: Guy Steele <gls@Think.COM>'s message of Tue, 6 Dec 88 14:29:22
EST
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881206-175806-7312@Xerox>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Tue, 10 Jan 89 18:49 EST
Resent-Message-ID: <890110184912.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
For Current Practice, Envos Medley implements APPEND-ATOM:IGNORE; it was
more compatible with the Interlisp definition of APPEND.
∂10-Jan-89 1552 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:52:01 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 10 Jan 89 18:42:52 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 10 Jan 89 18:48:05 EST
Date: Tue, 10 Jan 89 18:48 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890110173307.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890110234853.0.BARMAR@OCCAM.THINK.COM>
Date: Tue, 10 Jan 89 17:33 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Date: Tue, 10 Jan 89 13:17 EST
From: Barry Margolin <barmar@Think.COM>
...
Rationale:
COPY-LIST is the simplest list-copying primitive.
...
In my book it's the -only- list-copying primitive. COPY-TREE doesn't
copy lists, it copies trees. Abstractly, there is no relationship
between the two except for people who think it's a bug that
(MEMBER 'A '(B (A) C))
doesn't find A in the given list.
If you're going to play semantic games, MEMBER searches sets, not lists.
If the definition of what it means to "copy a list" were obvious, CLtL
wouldn't need three sentences to describe it, it could simply say
"copies the list and returns the copy." Also, the description of
COPY-LIST doesn't mention that it is THE copier for the abstract type
"list" (the first sentences of the COPY-ALIST and COPY-TREE descriptions
DO say something to that effect for their respective abstract types), it
merely describes the operation of the function. Readers of standards
are not supposed to make assumptions based on names, so one can't assume
that copying lists in general implies COPY-LIST.
I don't think there's much issue here, but I'm happy to go along with it
if you think there is.
If we do proceed, I'd go so far as to say that Kathy might want to
document that wherever in plain text the phrase "copy the list" is used,
the equivalent of COPY-LIST is intended, that wherever in plain text the
phrase "copy the tree" is used, the equivalent of COPY-TREE is intended,
and that wherever in plain text the phrase "copy the alist" is used, the
equivalent of COPY-ALIST is intended. This would save us having 42 more
of these issues come up now that you've opened this particular box
marked "Pandora"...
I agree with you in principle, but I don't think this particular case is
so obvious that it goes without saying. What CLtL actually says in this
case is "the property list of the new symbol will be a copy of SYM's."
The problem is that COPY-TREE produces a result that has many of the
same properties as that produced by COPY-LIST, and in the case of
copying property lists it may not be so obvious which of these
properties are important. If there were a COPY-PLIST function it would
be pretty obvious that its semantics were intended; if there were such a
function, it might conceivably copy even elements differently from odd
elements, if we were to decide that indicators and values had different
important properties. An implementor of COPY-SYMBOL might think that
such different semantics are necessary even without the existence of
such a function.
I don't think the Pandora's box is that big. I don't think there are
many places where lists or trees are automatically copied. I can't
think offhand of ANY place where it might say "copy the tree" (I think
the only standard functions that know about trees as an abstract object
are TREE-EQUAL, COPY-TREE, SUBST and its variants, and SUBLIS and its
variants).
The Pandora's box isn't empty, though. I just noticed that COPY-SEQ
doesn't specify precisely how the sequence is copied. In fact, COPY-SEQ
says that it is equivalent to (SUBSEQ sequence 0), and the description
of SUBSEQ says "it never shares storage with an old sequence." You and
I know that the latter means "it never shares top-level storage", but it
could easily be interpreted to mean that none of the storage of the
original object is shared. We know that because we understand how Lisp
differentiates between a structured object and its contents, but most
traditional languages don't make such a distinction, so I think it is
important that the CL standard not presume this abstract understanding.
I'm currently writing a paper about copying and equality that I hope to
have done in time to distribute at the meeting, and it has sensitized me
to the need to specify these things explicitly. Also, if we don't
correct them now, I'll wager we'll have to after the standard goes out
for public review (I've seen the kinds of comments that come back from
ANSI public reviews, and they can find an amazing number of nits to
pick).
barmar
∂10-Jan-89 1556 CL-Cleanup-mailer Possible issue: GCD-NO-ARGUMENTS
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:54:01 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09063; 10 Jan 89 23:35 GMT
Date: Tue, 10 Jan 89 23:37:00 GMT
Message-Id: <15927.8901102337@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Possible issue: GCD-NO-ARGUMENTS
To: cl-cleanup@sail.stanford.edu, gls@think.com
Cc: richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Richard Tobin, who shares my office, has mentioned from time to time
that both (LCM) and (GCD) are wrong in CLtL, because LCM should allow
zero arguments and GCD should not. I see there is a cleanup issue for
LCM, and, if he is right, we should also chage GCD. So I asked for a
message stating his views on GCD. Here it is:
---- Start of forwarded text ----
Date: Tue, 10 Jan 89 20:52:26 GMT
From: Richard Tobin <R.Tobin@uk.ac.ed>
To: jeff@ed.aiai
Subject: GCD in CLtL
CLtL defines (gcd) as zero, which seems bogus to me. It should be
undefined, as should (gcd 0). The reasoning goes like this:
Let f be a function that takes an arbitrary number of arguments. If
there is an "identity" i, such that (f -some-args- i) is always the
same as (f -some-args-), then the value of (f) should be the same as
(f i), if that is defined. So far, so good.
But 0 is certainly not the greatest common divisor of 0. All integers
divide 0. Furthermore, (gcd -some-args- -another-arg-) should never be
greater than (gcd -some-args-), since it adds a constraint to the set of
numbers of which we are computing the greatest. But if (gcd 0) is 0,
(gcd 4 0) (ie 4) is greater then (gcd 0).
The only reasonable value for (gcd 0) would be some representation of
infinity, but we don't have one, so it should be undefined.
-- Richard
---- End of forwarded text ----
∂10-Jan-89 1610 CL-Cleanup-mailer cleanup ballot
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 10 Jan 89 16:10:28 PST
Posted-Date: Tue, 10 Jan 89 16:10:16 PST
Message-Id: <8901110010.AA02905@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
id AA02905; Tue, 10 Jan 89 16:10:22 PST
To: cl-cleanup@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: cleanup ballot
Date: Tue, 10 Jan 89 16:10:16 PST
Sender: goldman@vaxa.isi.edu
Ballot submitted by Neil Goldman (Goldman@vaxa.isi.edu)
Organization: USC/Information Sciences Institute
Status: Interested Party -- not official position of organization
ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
YES
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
YES
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Version 5, 5-Dec-88, Mailed 5 Dec 88
YES
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
YES
DECLARATION-SCOPE:NO-HOISTING
YES
DECLARATION-SCOPE:LIMITED-HOISTING
NO
Version 4, 15-Nov-88, Mailed 9-Dec-88
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Version 4, 5-Dec-88, Mailed 5-Dec-88
YES
DECLARE-TYPE-FREE:ALLOW
Version 8, 7-Dec-88, Mailed 9-Dec-88
YES
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
YES
DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
YES
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
YES
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
NO
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
NO
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
YES
DESCRIBE-INTERACTIVE:NO
NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
YES
EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
YES
EXIT-EXTENT:MINIMAL
NO
EXIT-EXTENT:MEDIUM
YES
Version 5, 12-Dec-88, Mailed 12-Dec-88
EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
ABSTAIN
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
NO
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
YES
Version 4, 7-Dec-88, Mailed 12-Dec-88
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
ABSTAIN
FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
YES
FUNCTION-COMPOSITION:NEW-FUNCTIONS
NO
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
NO
Version 4, 12 Dec 88, Mailed 12 Dec 88
FUNCTION-DEFINITION:FUNCTION-SOURCE
Version 2, 09-Dec-88 , Mailed 9 Dec 88
NO
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
YES
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
NO
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
YES
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Version 7, 8-Dec-88, Mailed 9-Dec-88
YES
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
NO
HASH-TABLE-TESTS:ADD-EQUALP
Version 2, 8-Dec-88, Mailed 8 Dec 88
YES
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
YES
LAMBDA-FORM:NEW-MACRO
Version 4, 22-Nov-88, Mailed 8-Dec-88
NO
LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
YES
LISP-SYMBOL-REDEFINITION:DISALLOW
Version 5, 22-Nov-88, Mailed 8 Dec 88
YES
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
NO
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
YES
NTH-VALUE:ADD
Version 4, 8-Dec-88, Mailed 8 Dec 88
YES
PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
YES
PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
YES
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Version 1 27-Jun-88, Mailed 7 Oct 88
YES
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
YES
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
YES
PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
YES
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Version 3, 9-Oct-88, Mailed 14-Oct-88
YES
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
YES
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
NO
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
NO
REST-LIST-ALLOCATION:MAY-SHARE
YES
REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
NO
RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
YES
ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
YES
[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
YES
SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
NO
SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
YES
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
YES
STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
YES
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
NO
STREAM-ACCESS:ADD-TYPES-ACCESSORS
YES
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
NO
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
YES
SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
YES
SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
YES
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
YES
TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
ABSTAIN
TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
ABSTAIN
TEST-NOT-IF-NOT:FLUSH-ALL
NO
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
YES
Version 3, 1 Dec 88 mailed 9 dec
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
YES
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
YES
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
YES
∂10-Jan-89 1610 CL-Cleanup-mailer cleanup ballot
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 10 Jan 89 16:10:28 PST
Posted-Date: Tue, 10 Jan 89 16:10:16 PST
Message-Id: <8901110010.AA02902@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
id AA02902; Tue, 10 Jan 89 16:10:20 PST
To: cl-cleanup@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: cleanup ballot
Date: Tue, 10 Jan 89 16:10:16 PST
Sender: goldman@vaxa.isi.edu
Ballot submitted by Neil Goldman (Goldman@vaxa.isi.edu)
Organization: USC/Information Sciences Institute
Status: Interested Party -- not official position of organization
ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
YES
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
YES
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Version 5, 5-Dec-88, Mailed 5 Dec 88
YES
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
YES
DECLARATION-SCOPE:NO-HOISTING
YES
DECLARATION-SCOPE:LIMITED-HOISTING
NO
Version 4, 15-Nov-88, Mailed 9-Dec-88
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Version 4, 5-Dec-88, Mailed 5-Dec-88
YES
DECLARE-TYPE-FREE:ALLOW
Version 8, 7-Dec-88, Mailed 9-Dec-88
YES
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
YES
DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
YES
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
YES
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
NO
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
NO
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
YES
DESCRIBE-INTERACTIVE:NO
NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
YES
EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
YES
EXIT-EXTENT:MINIMAL
NO
EXIT-EXTENT:MEDIUM
YES
Version 5, 12-Dec-88, Mailed 12-Dec-88
EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
ABSTAIN
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
NO
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
YES
Version 4, 7-Dec-88, Mailed 12-Dec-88
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
ABSTAIN
FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
YES
FUNCTION-COMPOSITION:NEW-FUNCTIONS
NO
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
NO
Version 4, 12 Dec 88, Mailed 12 Dec 88
FUNCTION-DEFINITION:FUNCTION-SOURCE
Version 2, 09-Dec-88 , Mailed 9 Dec 88
NO
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
YES
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
NO
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
YES
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Version 7, 8-Dec-88, Mailed 9-Dec-88
YES
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
NO
HASH-TABLE-TESTS:ADD-EQUALP
Version 2, 8-Dec-88, Mailed 8 Dec 88
YES
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
YES
LAMBDA-FORM:NEW-MACRO
Version 4, 22-Nov-88, Mailed 8-Dec-88
NO
LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
YES
LISP-SYMBOL-REDEFINITION:DISALLOW
Version 5, 22-Nov-88, Mailed 8 Dec 88
YES
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
NO
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
YES
NTH-VALUE:ADD
Version 4, 8-Dec-88, Mailed 8 Dec 88
YES
PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
YES
PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
YES
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Version 1 27-Jun-88, Mailed 7 Oct 88
YES
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
YES
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
YES
PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
YES
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Version 3, 9-Oct-88, Mailed 14-Oct-88
YES
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
YES
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
NO
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
NO
REST-LIST-ALLOCATION:MAY-SHARE
YES
REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
NO
RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
YES
ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
YES
[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
YES
SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
NO
SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
YES
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
YES
STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
YES
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
NO
STREAM-ACCESS:ADD-TYPES-ACCESSORS
YES
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
NO
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
YES
SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
YES
SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
YES
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
YES
TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
ABSTAIN
TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
ABSTAIN
TEST-NOT-IF-NOT:FLUSH-ALL
NO
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
YES
Version 3, 1 Dec 88 mailed 9 dec
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
YES
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
YES
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
YES
∂10-Jan-89 2248 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Jan 89 22:48:18 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03151g; Tue, 10 Jan 89 22:44:06 PST
Received: by bhopal id AA03335g; Tue, 10 Jan 89 22:46:24 PST
Date: Tue, 10 Jan 89 22:46:24 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901110646.AA03335@bhopal>
To: Gray@DSG.csc.ti.com
Cc: masinter.pa@Xerox.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: David N Gray's message of Tue, 10 Jan 89 10:57:15 CST <2809443435-15097074@Kelvin>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
Well, one of two things needs to be done (and fast!). Either:
1. merge SPECIAL-TYPE-SHADOWING:CLARIFY into DECLARE-TYPE-FREE,
enlarging the latter to cover PROCLAIM as well as DECLARE.
2. keep two separate issues, but reconcile the semantics of
nested, non-identical declarations.
Either way, the "reconcilation" will have to be done [I tend to
favor two separate issues at this point.]
I think you are right that the matter of semantics for nested declarations
isn't adequately treated in the DECLARE-TYPE-FREE proposal. Sigh. In
order to accommodate those who argued that mechanical code production
might not be able to guarantee a true SUBTYPE relation for the inner
declarations, I would go for a version that treated an inner declaration
as if it were the intersection of the outter one. How about you? In
the example:
(proclaim '(type some-var (or symbol integer)))
(let ((x (mumble)))
(declare (type x number))
...
(locally (declare (type x (or bit character)))
;; 'x' is effectively declared to be of type BIT here
))
the inner declarations are not subtypes of the outter ones, but at
least the intersections are non-null.
-- JonL --
∂11-Jan-89 0004 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Jan 89 00:04:40 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03190g; Wed, 11 Jan 89 00:00:30 PST
Received: by bhopal id AA03531g; Wed, 11 Jan 89 00:02:47 PST
Date: Wed, 11 Jan 89 00:02:47 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901110802.AA03531@bhopal>
To: cperdue@Sun.COM
Cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: Cris Perdue's message of Tue, 10 Jan 89 10:41:42 PST <8901101841.AA13760@clam.sun.com>
Subject: Issue: SETF-SUB-METHODS (Version 5)
re: Consider example 6.
(setq s (setq r (list 'a 1 'b 2 'c 3)))
(setf (getf r 'b) (progn (setq r nil) 6))
r ==> (b 6)
s ==> (a 1 b 2 c 3)
I find the SETF expression naturally maps to:
(setf r (put-plist r 'b (progn (setq r nil) 6)))
This is the conceptual bug you make if you fail to notice the
distinction between evaluating the "value-producing subforms" and
"reading the value" out of the generalized location. The top part
of the second page of the proposal tries to warn the reader about
this by saying:
"``reading the value'' of a generalized variable reference is not
part of the series of evaluatons that must be done in left-to-right
order."
Of course, Test Case 6 is a worst-case pun of sorts, since "reading
the value" is exactly the same set of computer instructions as
"evaluating the value-producing subforms". It is a malice-aforethough
worst-case test, just to illustrate the point. [Incidentally, these are
Test Cases rather than Examples.]
We are fully aware that this is (A) a "fine point" and (B) a very
detailed point. However, failure to specify the details correctly will
lead to an incorrect implementation, especially in regard to the Test
Case 2. A previous proposal had that flaw, and we didn't notice until
actually coding it up and observing some previously working code
breaking. At least it isn't three pages of dense specification, since
most all of the three parts are isomorphic. But someone on the
subcommittee objected to a specification that was loosely worded like
"and similarly for CHAR-BIT and LDB etc.".
Since this is a Clarification (not an addition or change) of what we
think CLtL already says or implies, then a "No" vote is not nearly so
meaningful as an alternate clarification. I think you will find it
is not so easy a task to specify a general rule for sub-form semantics
if you base it only on the more limited reading of Test Case 6.
Test Case 2 must be accommodated also.
-- JonL --
∂11-Jan-89 0126 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Jan 89 01:26:22 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03246g; Wed, 11 Jan 89 01:22:16 PST
Received: by bhopal id AA03698g; Wed, 11 Jan 89 01:24:32 PST
Date: Wed, 11 Jan 89 01:24:32 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901110924.AA03698@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@Sail.Stanford.Edu
In-Reply-To: masinter.pa@Xerox.COM's message of 10 Jan 89 14:41 PST <890110-144153-6753@Xerox>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
re: The benefit of UPGRADE-ARRAY-ELEMENT-TYPE--namely, that it doesn't
CONS as much as the portable definition--seems very small and I don't think
it outweighs the cost.
No, Larry, the issue isn't that it "doesn't CONS as much", but that it
"doesn't CONS *at all*". This kind of issue is critical to some vendors,
such as Inference (which is why Joe Ginder was worrying about the
implicit consing in &rest args and in the sequence functions.)
See CLtL, p292, definition of ARRAY-DIMENSION. Applying the reasoning
that I am now trying to rebut, you would wind up with:
(defun array-dimension (array axis-number)
(elt (array-dimensions array) axis-number))
Why do you suppose that CLtL included ARRAY-DIMENSION in the standard?
How about ARRAY-TOTAL-SIZE? and ARRAY-ROW-MAJOR-INDEX?
-- JonL --
∂11-Jan-89 1217 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Jan 89 08:08:19 PST
Received: by ti.com id AA09880; Wed, 11 Jan 89 10:21:03 CST
Received: from Kelvin by tilde id AA22744; Wed, 11 Jan 89 10:08:23 CST
Message-Id: <2809527001-3602765@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 11 Jan 89 10:10:01 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: masinter.pa@Xerox.COM, CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-Reply-To: Msg of Tue, 10 Jan 89 22:46:24 PST from Jon L White <jonl@lucid.com>
> I think you are right that the matter of semantics for nested declarations
> isn't adequately treated in the DECLARE-TYPE-FREE proposal. Sigh. In
> order to accommodate those who argued that mechanical code production
> might not be able to guarantee a true SUBTYPE relation for the inner
> declarations, I would go for a version that treated an inner declaration
> as if it were the intersection of the outter one. How about you?
Agreed. That's what version 6 of DECLARE-TYPE-FREE said:
Clarify that if nested type declarations refer to the same variable,
then the value of the variable must be a member of the intersection of
the declared types.
∂11-Jan-89 1429 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 6)
Received: from SAPSUCKER.SCRC.Symbolics.COM ([128.81.41.223]) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:22:39 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 268293; Wed 11-Jan-89 14:42:07 EST
Date: Wed, 11 Jan 89 14:39 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 6)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890111143950.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Here's another draft. I changed only the proposal part. It tries
to correct the EQUALP problem we and others mentioned in mail.
Please read this very carefully before voting in favor of it.
There were a lot of Yes votes for the last version, which I think
had some serious bugs in it. This would be a very bad issue for
us to screw up.
Things that might need special attention:
- Moon contends that standard practice in Symbolics Lisp is
for instances to be compared using EQ under EQUALP, not by
descending. There may be performance issues involved here.
Some agreement needs to be reached.
- Neither the previous version of the proposal nor CLtL was
clear on what happens to pathnames under EQUALP. This showed
up when I converted the presentation below. That issue should
be addressed as well.
Hopefully if this version of the proposal isn't something you want to
vote yes for, at least it's in a suitable form for easy line-item
changes interactively in the meeting.
-----
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CLARIFICATION/CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
08-Jun-88, Version 2 by Masinter (add Benson's proposal)
23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
01-Oct-88, Version 4 by Masinter (fix description)
01-Oct-88, Version 5 by Pitman (correct wording, add discussion)
11-Jan-89, Version 6 by Pitman (attempt EQUALP correction)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:STATUS-QUO):
Clarify that EQUAL and EQUALP do not descend any structures or data types
other than the ones explicitly specified in CLtL.
Type EQUAL Behavior EQUALP Behavior
Number uses EQL uses =
Character uses EQL uses CHAR-EQUAL
Cons descends descends
Bit-Vector descends descends
String descends descends
Pathname magic per CLtL same as EQUAL
Structure uses EQ descends
other Array uses EQ descends
Instance (Standard-Object) uses EQ descends
Hash-Table uses EQ uses EQ
Other uses EQ uses EQ
Note that the order of this table is in some cases important, with upper
entries taking priority over lower ones.
Rationale:
There seem to be as many different equality primitives as there
are applications for them. None of the possible ways of changing
EQUAL or EQUALP are flawless. Given the inability to "fix" them,
it is better to leave them alone.
Current Practice:
We are unaware of any extensions to CLtL's set of operations,
although frequently users request them.
Cost to Implementors:
Since this seems to be compatible with the status quo, none.
Cost to Users:
Same
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
There seems to be wide debate about what the proper aesthetics for
how equality should work in Common Lisp. While the status quo is not
aesthetically more pleasing than the various alternatives, aesthetic
considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
Discussion:
An earlier version of this issue with various alternatives was distributed
at the June 1988 X3J13 meeting. Since
this is a frequently raised issue, we thought we should submit it
as a clarification although there is no change to CLtL.
Options for which we considered proposals were:
- removing EQUAL and EQUALP from the standard.
- changing EQUALP to descend structures.
- changing EQUALP to be case sensitive.
- adding a :TEST keyword to EQUAL.
- making EQUAL a generic function
All of these had some serious problems.
The cleanup committee supports option STATUS-QUO.
It would be useful if descriptions of EQUAL and EQUALP contained some sort
of additional commentary alluding to the complex issues discussed here.
The following is offered to the Editorial staff as a starting point:
Object equality is not a concept for which there is a uniquely
determined correct algorithm. The appropriateness of an equality
predicate can be judged only in the context of the needs of some
particular program. Although these functions take any type of
argument and their names sound very generic, EQUAL and EQUALP are
not appropriate for every application. Any decision to use or not
use them should be determined by what they are documented to do
rather than any abstract characterization of their function. If
neither EQUAL nor EQUALP is found to be appropriate in a particular
situation, programmers are encouraged to create another operator
that is appropriate rather than blame EQUAL or EQUALP for ``doing
the wrong thing.''
∂11-Jan-89 1430 CL-Cleanup-mailer Issue: APPLYHOOK-ENVIRONMENT (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:24:55 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 519255; 11 Jan 89 12:08:07 EST
Date: Wed, 11 Jan 89 12:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: APPLYHOOK-ENVIRONMENT (Version 2)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <890110-154231-6930@Xerox>
Message-ID: <890111120758.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
[X3J13 removed.]
For compatibility, we might want to consider either explicitly
permitting implementations to accept a third optional argument
to APPLYHOOK, which would be defined to be ignored, or else
actually require implementations to accept such an argument.
In the Cost to Users, you should highlight that the reason for
making the third argument optional is only for source compatibility
with CLtL. There should be no doubt that the value of *APPLYHOOK*
will only receive only two arguments.
Anyway, I approve of this proposal, whether the writeup is
ultimately ammended or not.
∂11-Jan-89 1431 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:25:07 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 519258; 11 Jan 89 12:20:25 EST
Date: Wed, 11 Jan 89 12:20 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890103003245.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890111122017.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Btw, I spoke last week on the phone to Jonathan Rees about this. He's not
yet gotten around to sending mail but he said...
- he doesn't think the ALLOW proposal is a good idea
- the ALLOW proposal is inconsistent with the proposal in
SYMBOL-MACROLET-SEMANTICS
He hadn't seen the actual LEXICAL proposal yet, but from my description
of the differences, he seemed pretty firm on the idea that it was the
right idea.
∂11-Jan-89 1430 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:24:38 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 519251; Wed 11-Jan-89 11:57:21 EST
Date: Wed, 11 Jan 89 11:57 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.edu
In-Reply-To: <890106-114801-253@Xerox>
Message-ID: <890111115708.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
A new proposal follows this initial commentary...
Current practice is ammended for Lucid and IIM. Please check for
accuracy.
The proposal is ammended per my responses to the following mail
from Larry:
Date: 6 Jan 89 11:37 PST
From: masinter.pa@Xerox.COM
I'd like to see the following changes to the proposal:
a) I don't like saying that the effect of adjusting an array which "is not
adjustable" is not defined. I don't see any reason not to say that it
signals an error.
It actually said this already (last paragraph), but it also had a
conflicting paragraph which I removed. Please check the result to see that
it is coherent.
b) I like defining clearly that "is not adjustable" means
"ADJUSTABLE-ARRAY-P returns false", and clarifying that MAKE-ARRAY may
return an adjustable array even if the :ADJUSTABLE array is given NIL.
Right. I think I made this more clear.
c) I would like to say that either all arrays are adjustable, or else only
those that are specified with :ADJUSTABLE true, and that a conformal
implementation will document which behavior it uses.
I think this complicates the user model because it suggests that there is
advantage to be had from knowing that all arrays are adjustable. I can't
imagine any serious way in which a truly portable program could take
advantage of this information even if we could guarantee it.
In fact, though, the Symbolics implementation makes -most- but not all
arrays adjustable. There are some odd situations involving displaced arrays
where I'm told the arrays are not adjustable. So we couldn't be conforming if
you did this. I therefore made no change.
d) Rename the proposal name from "STATUS-QUO" to "MAY-BE-ADJUSTABLE" and
change "Document clearly" to "Specify".
It wasn't clear what the noun was in "may be adjustable", so I avoided this
name and tried to pick a name that had no connotations at all: DONKEY.
(Surely there's no chance anyone will even think to connect the spirit of
this proposal or the character of its author with derogatory synonyms,
stubborn animals, or Massachusetts liberal democrats... :-) Anyway, hopefully
this will avoid wasted discussion on a supposedly semantics-free symbol.
Is this OK?
Except for item C, I think I've done the best I could. Proposal follows...
-----
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289)
Category: CLARIFICATION/CHANGE
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
Status: For Internal Discussion
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
Some of the original Common Lisp designers assert that the
:ADJUSTABLE option exists in order to allow a user to select
between getting adjustable and non-adjustable arrays.
Others of the original Common Lisp designers assert that the
:ADJUSTABLE option existed to permit implementations in which
making all arrays adjustable was very expensive to make some
arrays not adjustable.
The former camp therefore believes that :ADJUSTABLE NIL means
that the array MUST be non-adjustable. The latter camp believes
that :ADJUSTABLE NIL means that the array MIGHT be non-adjustable.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' Although this sentence
is slightly ambiguous (one might argue that :ADJUSTABLE NIL
involves supplying the :ADJUSTABLE option), it is generally
interpreted to mean that ``... with :ADJUSTABLE T.''
One problem is that since ADJUSTABLE-ARRAY-P does not predicate
whether the :ADJUSTABLE option was provided, then
ADJUSTABLE-ARRAY-P is not an appropriate predicate in all
implementations to determine whether an array is adjustable.
Technically, :ADJUSTABLE NIL could create and adjustable array
(one for which ADJUSTABLE-ARRAY-P returns true), and yet
ADJUST-ARRAY might refuse to adjust it (if it had recorded a
separate bit saying whether :ADJUSTABLE T had been specified
and used that bit for ADJUST-ARRAY). Fortunately, this problem
has not been observed to occur in practice, but it is present
in principle.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY. That expectation is violated by
legitimate implementations, since it is permissible for an
implementation to create an adjustable array even though it has
not been asked for, and since calling adjust array on such an
array "is an error" (and hence the behavior can be extended).
This perceived lack of error checking may become a legitimate
portability error to someone who has debugged his code in a
an implementation where :ADJUSTABLE NIL arrays might still be
adjustable and then tried ported his code to an implementation
which is more conservative in its interpretation.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY):
Define that omitting the :ADJUSTABLE option to MAKE-ARRAY or
explicitly supplying :ADJUSTABLE NIL may not guarantee a
non-adjustable array.
Define that ADJUSTABLE-ARRAY-P -must- be true of an array created
using :ADJUSTABLE T.
Define that ADJUSTABLE-ARRAY-P -might- be true of an array created
with no :ADJUSTABLE option or with :ADJUSTABLE NIL, but that it
-might- return false.
Clarify that the implication of the above is that saying that an
array A "is adjustable" means that (ADJUSTABLE-ARRAY-P A) => true.
Further clarify that the adjustability of an array has no necessary
relation to any value was given (or not given) as the :ADJUSTABLE
option in the call to MAKE-ARRAY which created the array A.
Clarify that there is no portable way to create a non-adjustable
array (that is, an array for which ADJUSTABLE-ARRAY-P is
guaranteed to return false).
Change the description of ADJUST-ARRAY to say that if an attempt
is made to adjust an array which is not adjustable (that is, an
array for which ADJUSTABLE-ARRAY-P would return false), an error
will be signalled.
Clarify that this legitimizes ADJUSTABLE-ARRAY-P as an appropriate
predicate to determine whether ADJUST-ARRAY will reliably succeed.
Rationale:
This effectively makes the status quo explicit.
While changing this to a tighter interpretation would be desirable, some
implementations have suggested that such a change might be very expensive
or impossible given their existing data storage layouts.
Although technically the changes to ADJUST-ARRAY are incompatible changes
from the spec, it's not believed that there are any implementations which
deviate, so we're still categorizing this as a clarification.
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and is compatible with this proposal.
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
in all cases, and are compatible with this proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic.
Discussion:
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
∂11-Jan-89 1431 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:25:42 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 519282; Wed 11-Jan-89 13:09:06 EST
Date: Wed, 11 Jan 89 13:08 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890105-221446-191@Xerox>
Message-ID: <890111130857.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 5 Jan 89 22:14 PST
From: masinter.pa@Xerox.COM
The example I keep coming back to is one where it isn't so much that the
local declaration is easy to enforce as it is where it is difficult *not*
to enforce it.
Suppose I have
(defun frob (delta)
(flet ((more (x) (+ x delta)))
;; if you like, put (declare (inline more)) here
(typecase delta
(float (locally (declare (type float delta))
... (more rho ) ... ))
((signed-byte 8)
(locally (declare (type (signed-byte 8) delta))
... (more zz) ... ))
...)))
[Parens added.]
Even without the inline, it is a common & legal transformation to do inline
substitution on "small" fletted functions.
Absolutely. But not textually. Semantically. For example, you already
have to watch for:
(defun add (x y) (+ x y))
(defun frob (delta)
(flet ((more (x) (add x delta)))
(flet ((add (x y) (- x y)))
... (more x) ...)))
Even though the reference "delta" in the definition of more isn't
within the lexical scope of the local declaration, it *is* the same
delta.
Right. But that itself implies nothing.
While its not impossible to maintain a separate contour in order to
segregate the type declarations, it seems like unnecessary work,
It is not unnecessary. You cannot just substitute a piece of unadorned
text. You have to do the substitution at a lower level using an adorned
call tree or else you have to have resolved out all the relevant lexical
things before you start merging source (ie, you have to have assured that
the flet problem is not going to happen). If your approach is the former,
it's possible (maybe even "easy" or at least "standard practice") to
represent every reference to a variable with a pointer to the lexical
environment it came from, so you can get the lookup right. If your
approach is the latter, then it's possible to make all the declarations
explicit as you do the code-walk looking for flets and whatnot so that
you don't have to rely on DECLARE info afterward. In that case, the result
of your traversal should be:
(defun frob (delta)
(typecase delta
(float ... ((lambda (x) (+ x delta)) rho) ...)
((signed-byte 8)
... ((lambda (x) (+ x delta)) zz) ... )
...))
... and in fact, the declaration is quite useful if "more" is inlined.
Actually, in this case it doesn't provide any information that
the compiler can't figure out from the TYPECASE. A good compiler
is not limited in its type inferencing to what has been declared.
It can tell that no SETQ is going on, so it can propagate the type
from the TYPECASE directly without even the aid of the DECLARE.
Let's look at a better example which is opaque to the compiler:
(defun frob (n m)
(frob1 (cond ((and (typep n 'fixnum) (typep m 'fixnum)) 'fixnum)
((and (typep n 'float) (typep m 'float)) 'float)
(t 't))
n m))
(defun frob1 (type n m)
(flet ((zap () (+ n m)))
(case type
(fixnum (locally (declare (fixnum n m)) (zap)))
(float (locally (declare (float n m)) (zap)))
(otherwise (zap)))))
In this case, I agree you're potentially losing some slight amount
of efficiency, but ...
(a) You could use MACROLET instead to get back that efficiency.
I personally believe that it is stylistically the correct
thing for this situation.
(b) There is a twin brother of this example which I don't want to
let through, and which your proposal would force me to reckon
with:
(defun frob (n m)
(frob1 (cond ((and (typep n 'fixnum) (typep m 'fixnum)) 'fixnum)
((and (typep n 'float) (typep m 'float)) 'float)
(t 't))
#'(lambda ()
(declare (special n m))
(let ((nn n) (mm m))
(setq n nil m nil)
(setq n nn m mm)
(+ n m)))
n m))
(defun frob1 (type fn n m)
(declare (special n m))
(flet ((zap () (funcall fn)))
(case type
(fixnum (locally (declare (fixnum n m)) (zap)))
(float (locally (declare (float n m)) (zap)))
(otherwise (zap)))))
In your interpretation, this code is in error, while in my
interpretation, this code is valid. I consider it a gross
modularity violation for the effect of a type declaration to
have other than lexical scope.
The only alternatives seem to me to be:
- Don't do local type declarations on special variables.
[This costs efficiency in other places, so your proposal
would be trading one kind of efficiency barrier for
another.]
- Scope type declarations for special variables differently
for lexical and dynamic variables. Curiously, you would
have lexical variables enforce their type declarations
dynamically, and dynamic variables enforce their type
declarations lexically.
- Scope all type declarations lexically.
The only one I have any support for is still the third, which
is Moon's LEXICAL proposal.
∂11-Jan-89 1458 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89 14:46:01 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 519656; Wed 11-Jan-89 17:44:14 EST
Date: Wed, 11 Jan 89 17:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19890103003245.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Supersedes: <890111122017.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890111174402.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 11 Jan 89 12:20 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Btw, I spoke last week on the phone to Jonathan Rees about this. He's not
yet gotten around to sending mail but he said...
- he doesn't think the ALLOW proposal is a good idea
- the ALLOW proposal is inconsistent with the proposal in
SYMBOL-MACROLET-SEMANTICS
Oops. I meant to say "SYMBOL-MACROLET-DECLARE", of course.
He hadn't seen the actual LEXICAL proposal yet, but from my description
of the differences, he seemed pretty firm on the idea that it was the
right idea.
∂11-Jan-89 1513 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 14:54:11 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 89 14:47:55 PST
Date: 11 Jan 89 14:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Wed, 11 Jan 89
01:24:32 PST
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, cl-cleanup@Sail.Stanford.Edu
Message-ID: <890111-144755-10740@Xerox>
I'll rephrase my statement:
The benefit of UPGRADE-ARRAY-ELEMENT-TYPE--namely, that it doesn'tCONS
while the simple portable definition does--seems very small; I don't think
it outweighs the costs of adding it to the existing language. If
UPGRADE-ARRAY-ELEMENT-TYPE were already part of Common Lisp, I don't I
probably would not vote to take it out, even though it seems of limited
utility. Since it isn't in the language, I vote against adding it.
I also think that UPGRADE-ARRAY-ELEMENT-TYPE is strictly less useful than
ARRAY-DIMENSION and ARRAY-TOTAL-SIZE and that a first-principle argument
would be made against it. UPGRADE-ARRAY-ELEMENT-TYPE answers only a
hypothetical issue, viz: what *would* the type of this array be if I *were*
to upgrade it.
As I think about it, I'm not sure why we rule out the possibility that the
upgrading of arrays might happen differently for different arrays: for
example, I might have an algorithm that "upgraded" all simple
non-adjustable arrays with ARRAY-TOTAL-SIZE less than 2 to ELEMENT-TYPE T,
but be more strict about larger arrays. The major part of the proposal
("Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is not
*, to be true if and only if <x> is an array that could be the result of
giving <type> as the :element-type argument to MAKE-ARRAY.") could be kept,
and the part that talks about upgrading (Clarify that "upgrading" implies a
movement upwards in the type- hierarchy lattice.) would just have to be
recast in terms of a specific array.
This is counter to the part that says "Clarify that upgrading an array
element-type is independent of any
other property of arrays, such as rank, adjustability, fill-pointers,
displacement etc."
but I wonder now if that is a clarification -- is it a Change? -- and if it
is necessary.
∂11-Jan-89 1514 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 5)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:51:37 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07416; 11 Jan 89 20:14 GMT
Date: Wed, 11 Jan 89 20:16:22 GMT
Message-Id: <18372.8901112016@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: SETF-SUB-METHODS (Version 5)
To: Jon L White <@sail.stanford.edu:jonl@lucid.com>, cperdue@sun.com
In-Reply-To: Jon L White's message of Wed, 11 Jan 89 00:02:47 PST
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
I thought about this issue for a long time this morning and found
it very confusing. Eventualy, I decided that the proposal was
probably right, but it could have been better explained. What
finally convinced me was the thinking below (which I do not think
is necessarily the better explanation).
(setf (getf -variable- -expr1-) -expr2-)
expands into something like:
(let* ((#:temp0 -variable-) ;let's assume we do this binding for now.
(#:temp1 -expr1-) ;in the example, -expr2- is just 'B.
(#:temp2 -expr2-)) ;in the example, this does the setq.
(setq -variable-
(list-putprop [ ? ] #:temp1 #:temp2))
#:temp2)
Let's assume LIST-PUTPROP returns the entire plist, which may be a new
list or a modification of the old.
Now the question is: what goes in [ ? ]? If it's #:temp0, then in
(setq s (setq r (list 'a 1 'b 2 'c 3)))
(setf (getf r 'b) (progn (setq r nil) 6))
LIST-PUTPROP would get the original value or R (before it was set to
NIL), and the results would be:
r ==> (a 1 b 6 c 3)
s ==> (a 1 b 6 c 3) or (a 1 b 2 c 3)
The other alternative is that [ ? ] is R. Then LIST-PUTPROP gets the
new value of R (i.e., nil), and the results are:
r ==> (b 6)
s ==> (a 1 b 2 c 3)
Now suppose we're doing
(setf (getf (car -variable-) -expr1-) -expr2-)
This expands into
(let* ((#:temp0 -variable-)
(#:temp1 -expr1-)
(#:temp2 -expr2-))
(setf (car #:temp0)
(list-putprop (car #:temp0) #:temp1 #:temp2))
#:temp2)
Here, (car #:temp0) acts as a sort of pointer to what we want to
change. We can't point to a car (only to a whole cons), but we
want the car of that cons, not the cons that happens to be the
value of the variable later on. That's what (car ...) means as
a place. But a variable as a place wants a "pointer" to that
variable, not to it's value, because that's what a variable means
as a place. And such a "pointer" is just the variable itself.
This suggests that [ ? ] should be R. That is, we should dereference
the "pointer" when calling LIST-PUTPROP.
-- Jeff
∂11-Jan-89 1515 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 5)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 13:18:01 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA07029; Wed, 11 Jan 89 13:19:36 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA12243; Wed, 11 Jan 89 13:16:14 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA01716; Wed, 11 Jan 89 13:17:20 PST
Date: Wed, 11 Jan 89 13:17:20 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901112117.AA01716@clam.sun.com>
To: jonl@lucid.com
Subject: Re: Issue: SETF-SUB-METHODS (Version 5)
Cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
I have read Jeff Dalton's recent discussion as well as JonL's
email, and it is quite possible that I will change my
view as to what the semantics should be stated to be.
I'm not going to vote now for this proposal as it stands --
will think about it harder after X3J13.
-Cris
∂11-Jan-89 1516 CL-Cleanup-mailer Re: New proposed issue APPEND-ATOM
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 13:38:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 89 13:34:46 PST
Date: 11 Jan 89 13:33 PST
From: masinter.pa@Xerox.COM
Subject: Re: New proposed issue APPEND-ATOM
In-reply-to: Guy Steele <gls@Think.COM>'s message of Tue, 6 Dec 88 14:29:22
EST
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890111-133446-10438@Xerox>
The proposal labelled
Proposal (APPEND-ATOM:IGNORE):
is referred to by Examples (APPEND-ATOM:DOTTED).
The last sentence of the APPEND-ATOM:IGNORE is hard for to parse. I'd say
"Point out that if all of the arguments are non-lists, the result of APPEND
or NCONC can be a non-list."
We've gotten no opinions on this issue. If I believe the phrase in CLtL
that says that "unless otherwise specified, a 'list' is a proper list",
then APPEND-ATOM:ERROR is a clarification and APPEND-ATOM:DOTTED is a
change.
∂11-Jan-89 1517 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 14:18:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 13:59:43 PST
Date: 11 Jan 89 13:59 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-SUB-METHODS (Version 5)
In-reply-to: cperdue@Sun.COM (Cris Perdue)'s message of Wed, 11 Jan 89
13:17:20 PST
To: cperdue@Sun.COM (Cris Perdue)
cc: jonl@lucid.com, cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
Message-ID: <890111-135943-10535@Xerox>
I believe that this will get voted on at this meeting unless there is a
successful motion to table it.
∂11-Jan-89 1522 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 15:21:49 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 15:20:33 PST
Date: 11 Jan 89 15:20 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 11 Jan 89 17:44 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890111-152033-10869@Xerox>
I've been convinced that LEXICAL is reasonable ...
Version 9 was released to X3J13 & I think we can probably vote on the
LEXICAL proposal at the meeting.
∂11-Jan-89 1514 CL-Cleanup-mailer Ballot response
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:48:30 PST
Return-Path: <barmar@fafnir.think.com>
Received: from sauron.think.com by Think.COM; Wed, 11 Jan 89 11:14:14 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 11 Jan 89 11:25:35 EST
Date: Wed, 11 Jan 89 11:26 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Ballot response
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881212-181649-5908@Xerox>
Supersedes: <19890109165147.5.BARMAR@OCCAM.THINK.COM>
Message-Id: <19890111162622.3.BARMAR@OCCAM.THINK.COM>
Guy, here are my X3J13 ballot responses. Please review them ASAP and
let me know if you have any objections. I'd like to mail these to
cl-cleanup by Tuesday morning.
barmar
Y ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
Y ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
Y CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Version 5, 5-Dec-88, Mailed 5 Dec 88
Y CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
Y DECLARATION-SCOPE:NO-HOISTING
N DECLARATION-SCOPE:LIMITED-HOISTING
Version 4, 15-Nov-88, Mailed 9-Dec-88
Reason: LOCALLY can always be used to hoist a declaration around an
initial value form.
A DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Version 4, 5-Dec-88, Mailed 5-Dec-88
C DECLARE-TYPE-FREE:ALLOW
C DECLARE-TYPE-FREE:LEXICAL
Version 9, 2-Jan-89, Mailed 7-Jan-89
I'd like to see more discussion of the relative merits of the two
different proposals. All of the benefit/cost section merely addresses
whether free type declarations should be allowed; I agree with this
part, but I'm unsure about which of the versions is better.
Y DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
Y DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
Y DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
Y DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
Y DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
A DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
A DESCRIBE-INTERACTIVE:NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
Y DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
Y EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
N EXIT-EXTENT:MINIMAL
Y EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
Reason: MEDIUM provides more useful semantics in one important case: if
an application has a top-level catch tag, and a cleanup handler does a
(throw 'top-level ...) while cleaning up during such a throw. Lack of
these semantics in Maclisp results in problems in Multics Emacs, whose
error handler prints a minibuffer message and then throws to the top
level, but if an error happens during a cleanup, the top-level catch is
no longer available, resulting in an infinite loop of "throw to
nonexistent tag" errors. This seems like it would be a common paradigm,
but unless there is a way for a cleanup handler to determine the context
of its invocation, MINIMAL makes this non-portable.
Y EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
Y FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
N FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Version 4, 7-Dec-88, Mailed 12-Dec-88
Reason: Tossing BIGNUM is a gratuitous incompatibility.
Y FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
Y FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
I FUNCTION-COMPOSITION:NEW-FUNCTIONS
I FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
In both cases, only if one of the TEST-NOT-IF-NOT proposals passes.
Y FUNCTION-DEFINITION:FUNCTION-SOURCE
Version 2, 09-Dec-88 , Mailed 9 Dec 88
Y FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
Y FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
Y GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
Y HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Version 7, 8-Dec-88, Mailed 9-Dec-88
Y HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
Y HASH-TABLE-TESTS:ADD-EQUALP
Version 2, 8-Dec-88, Mailed 8 Dec 88
Y IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
Y LAMBDA-FORM:NEW-MACRO
Version 4, 22-Nov-88, Mailed 8-Dec-88
Y LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
Y LISP-SYMBOL-REDEFINITION:DISALLOW
Version 5, 22-Nov-88, Mailed 8 Dec 88
N MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
Reason: When using the implementation's extensions, it is better to make
this obvious by having to specify the implementation-dependent package.
Y MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
N NTH-VALUE:ADD
Version 4, 8-Dec-88, Mailed 8 Dec 88
Reason: Naming values using a numeric index is like using arrays instead
of DEFSTRUCT. If there were a way to specify a value by a symbolic name
I'd go for that.
Y PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
Y PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
Y PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Version 1 27-Jun-88, Mailed 7 Oct 88
Y PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
Y PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
Y PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
Y RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Version 3, 9-Oct-88, Mailed 14-Oct-88
Y RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
Y REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
N REST-LIST-ALLOCATION:NEWLY-ALLOCATED
Y REST-LIST-ALLOCATION:MAY-SHARE
N REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
Reason: Allow implementation flexibility and useful optimization.
Y RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
Y ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
[The following are mutually exclusive]
Y SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
N SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
Reason: I don't think it's possible to define a version UNDERLYING-NAME
that returns a symbol and meets all the requirements.
Y SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
Y STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
Y STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
Y STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
Y STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
Y SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
Y SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
Y SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
Y TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
Y TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
N TEST-NOT-IF-NOT:FLUSH-ALL
N TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
Reason: Gratuitous incompatibility.
Y TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
Y UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
Y VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
To: gls
bcc: barmar-archived
Subject: Ballot response
In-Reply-To: <881212-181649-5908@Xerox>
Here are Thinking Machine's ballot responses. For all my No responses
I've included some justification.
Y ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
Y ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
Y CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Version 5, 5-Dec-88, Mailed 5 Dec 88
Y CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
Y DECLARATION-SCOPE:NO-HOISTING
N DECLARATION-SCOPE:LIMITED-HOISTING
Version 4, 15-Nov-88, Mailed 9-Dec-88
Reason: LOCALLY can always be used to hoist a declaration around an
initial value form.
A DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Version 4, 5-Dec-88, Mailed 5-Dec-88
C DECLARE-TYPE-FREE:ALLOW
C DECLARE-TYPE-FREE:LEXICAL
Version 9, 2-Jan-89, Mailed 7-Jan-89
I'd like to see more discussion of the relative merits of the two
different proposals. All of the benefit/cost section merely addresses
whether free type declarations should be allowed; I agree with this
part, but I'm unsure about which of the versions is better.
Y DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
Y DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
Y DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
Y DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
Y DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
A DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
A DESCRIBE-INTERACTIVE:NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
Y DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
Y EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
N EXIT-EXTENT:MINIMAL
Y EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
Reason: MEDIUM provides more useful semantics in one important case: if
an application has a top-level catch tag, and a cleanup handler does a
(throw 'top-level ...) while cleaning up during such a throw. Lack of
these semantics in Maclisp results in problems in Multics Emacs, whose
error handler prints a minibuffer message and then throws to the top
level, but if an error happens during a cleanup, the top-level catch is
no longer available, resulting in an infinite loop of "throw to
nonexistent tag" errors. This seems like it would be a common paradigm,
but unless there is a way for a cleanup handler to determine the context
of its invocation, MINIMAL makes this non-portable.
Y EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
Y FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
N FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Version 4, 7-Dec-88, Mailed 12-Dec-88
Reason: Tossing BIGNUM is a gratuitous incompatibility.
Y FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
Y FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
I FUNCTION-COMPOSITION:NEW-FUNCTIONS
I FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
In both cases, only if one of the TEST-NOT-IF-NOT proposals passes.
Y FUNCTION-DEFINITION:FUNCTION-SOURCE
Version 2, 09-Dec-88 , Mailed 9 Dec 88
Y FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
Y FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
Y GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
Y HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Version 7, 8-Dec-88, Mailed 9-Dec-88
Y HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
Y HASH-TABLE-TESTS:ADD-EQUALP
Version 2, 8-Dec-88, Mailed 8 Dec 88
Y IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
Y LAMBDA-FORM:NEW-MACRO
Version 4, 22-Nov-88, Mailed 8-Dec-88
Y LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
Y LISP-SYMBOL-REDEFINITION:DISALLOW
Version 5, 22-Nov-88, Mailed 8 Dec 88
N MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
Reason: When using the implementation's extensions, it is better to make
this obvious by having to specify the implementation-dependent package.
Y MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
N NTH-VALUE:ADD
Version 4, 8-Dec-88, Mailed 8 Dec 88
Reason: Naming values using a numeric index is like using arrays instead
of DEFSTRUCT. If there were a way to specify a value by a symbolic name
I'd go for that.
Y PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
Y PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
Y PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Version 1 27-Jun-88, Mailed 7 Oct 88
Y PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
Y PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
Y PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
Y RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Version 3, 9-Oct-88, Mailed 14-Oct-88
Y RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
Y REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
N REST-LIST-ALLOCATION:NEWLY-ALLOCATED
Y REST-LIST-ALLOCATION:MAY-SHARE
N REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
Reason: Allow implementation flexibility and useful optimization.
Y RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
Y ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
[The following are mutually exclusive]
Y SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
N SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
Reason: I don't think it's possible to define a version UNDERLYING-NAME
that returns a symbol and meets all the requirements.
Y SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
Y STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
Y STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
Y STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
Y STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
Y SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
Y SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
Y SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
Y TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
Y TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
N TEST-NOT-IF-NOT:FLUSH-ALL
N TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
Reason: Gratuitous incompatibility.
Y TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
Y UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
Y VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
∂11-Jan-89 1522 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 15:21:37 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 15:18:27 PST
Date: 11 Jan 89 15:17 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DYNAMIC-EXTENT (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
line-fold: NO
cc: masinter.pa@Xerox.COM
Message-ID: <890111-151827-10863@Xerox>
<<version number wrong, missing line-fold: NO>>
I don't have the time to "wordsmith" this issue, but I think it
is important enough to bring before X3J13; I think the idea
in the proposal is fine, but I just clipped some of David's words
into the old one.
I'd like to release this in DRAFT form, I'm less sure what
we can vote on.
Opinions? Volunteers to edit this further?
!
Status: For Internal Discussion
Forum: CLEANUP
Issue: DYNAMIC-EXTENT
References: Scope and Extent
Category: ADDITION
Edit history: 27-Jun-88, Version 1 by Pitman (as issue STACK-LET)
15-Nov-88, Version 2 by Pitman (issue renamed, major revision)
11-Jan-89, Version 3 by Masinter (Moon's proposal)
Related-Issues: REST-ARGUMENT-EXTENT, WITH-DYNAMIC-EXTENT
Problem Description:
Sometimes a programmer knows that a particular data structure
will have only dynamic extent. In some implementations, it is
possible to allocate such structures in a way that will make them
easier to reclaim than by general purpose garbage collection
(eg, on the stack or in some temporary area). Currently, however,
there is no way to request the use of such an allocation mechanism.
Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):
Introduce a new declaration called DYNAMIC-EXTENT. The arguments to
this declaration are names of variables. The declaration asserts that
the value which is initially held by the indicated variable will have
dynamic extent. [In the case of an iteration variable, the declaration
asserts that on every iteration, the initial value of that variable
for the iteration will have dynamic extent.]
It is permissible for an implementation to simply ignore this declaration.
In implementations which do not ignore it, the compiler (or interpreter)
is free to make whatever optimizations are appropriate given this
information; the most common optimization is to stack-allocate the
initial value of the object. What data types (if any) can have dynamic
extent will can vary from implementation to implementation.
Since stack allocation of the initial value entails knowing at the
object's creation time that the object can be stack-allocated, it is
not generally useful to declare DYNAMIC-EXTENT for variables for
which have no lexically apparent initial value. For example,
(DEFUN F ()
(LET ((X (LIST 1 2 3)))
(DECLARE (DYNAMIC-EXTENT X))
...))
would permit those compilers which wish to do so to stack-allocate the
list in X. However,
(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
(DEFUN F () (G (LIST 1 2 3)))
could not typically permit a similar optimization in G because it would
be a modularity violation for the compiler to assume facts about G from
within F. Only an implementation which was willing to be responsible for
recompiling F if G's definition changed incompatibly could stack-allocate
the list argument to G in F.
Other interesting cases are:
(PROCLAIM '(INLINE G))
(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
(DEFUN F () (G (LIST 1 2 3)))
and (DEFUN F ()
(FLET ((G (X) (DECLARE (DYNAMIC-EXTENT X)) ...))
(G (LIST 1 2 3))))
where some compilers might realize the optimization was possible and others
might not.
An interesting variant of this is the so-called `stack allocated rest list'
which can be achieved (in implementations supporting the optimization) by:
(DEFUN F (&REST X)
(DECLARE (DYNAMIC-EXTENT X))
...)
Note here that although the initial value of X is not explicit, the F
function is responsible for assembling the list X from the passed arguments,
so the F function can be optimized by the compiler to construct a
stack-allocated list instead of a heap-allocated list in implementations
which support such.
The meaning of a dynamic extent declaration is that execution of the
forms in the scope of the declaration will not "save" any "proper part"
of the initial value of the declared variable. To "save" an object
means to cause a reference to that object to be accessible outside the
dynamic extent of the form at the beginning of whose body the
declaration appears. An object can be "saved" by storing it with a
side-effecting operation and not replacing it with a different value
before the end of the dynamic extent, by using it as a component of a
freshly-allocated object that is itself "saved," by capturing it in a
function closure that is itself "saved," by returning it as a value, or
by transmitting it outside the dynamic extent with THROW. A "proper
part" of an object A is any object that is accessible at the beginning
of the scope of the declaration -only- by applying a function to A or to
a "proper part" of A. This means that any objects freshly allocated
during the construction of the initial value of the declared variable,
and not "saved" during the construction of that value, are "proper
parts" and can be allocated on a stack.
Examples:
In
(LET ((X (LIST 'A1 'B1 'C1))
(Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
(DECLARE (DYNAMIC-EXTENT X Y))
...)
The "proper parts" of X are three conses, and the "proper parts" of Y
are three other conses. None of the symbols A1, B1, C1, A2, B2, C2, or
NIL is a "proper part" of X or Y. However, if a freshly allocated
uninterned symbol had been used, it would have been a "proper part."
- - - - - - - -
(DOTIMES (I N)
(DECLARE (DYNAMIC-EXTENT I))
This is particularly instructive. Since I is an integer by the
definition of DOTIMES, but EQ and EQL are not necessarily equivalent for
integers, what are the "proper parts" of I, which this declaration
requires the body of the DOTIMES not to "save"? If the value of I is 3,
and the body does (SETQ FOO 3), is that an error? The answer is no, but
the interesting thing is that it depends on the implementation-dependent
behavior of EQ on numbers. In an implementation where EQ and EQL are
equivalent for 3, then 3 is not a "proper part" because (EQ I (+ 2 1))
is true, and therefore there is another way to access the object besides
going through I. On the other hand, in an implementation where EQ and
EQL are not equivalent for 3, then the particular 3 that is the value of
I is a "proper part", but any other 3 is not. Thus (SETQ FOO 3) is valid
but (SETQ FOO I) is erroneous. Since (SETQ FOO I) is erroneous in some
implementations, it is erroneous in all portable programs, but some other
implementations may not be able to detect the error.
- - - - - - - -
(LET ((X (LIST 1 2 3)))
(DECLARE (DYNAMIC-EXTENT X))
(PRINT X)
NIL)
PRINT does not "save" any part of its input.
This prints (1 2 3)
- - - - - - - -
(DO ((L (LIST-ALL-PACKAGES) (CDR L)))
((NULL L))
(DECLARE (DYNAMIC-EXTENT L))
(PRINT (CAR L)))
prints all packages; none of the newly-allocated list structures are saved.
- - - - - - - -
(DEFUN ADD (&REST X) (DECLARE (DYNAMIC-EXTENT X)) (APPLY #'+ X))
(ADD 1 2 3) => 6
I.e., useful way to declare that &REST lists have dynamic extent
- - - - - - - -
(DEFUN ZAP (X Y Z)
(DO ((L (LIST X Y Z) (CDR L)))
((NULL L))
(DECLARE (DYNAMIC-EXTENT L))
(PRIN1 (CAR L))))
(ZAP 1 2 3)
prints 123
- - - - - - - -
(DEFUN ZAP (N M)
;; Computes (RANDOM (+ M 1)) at relative speed of roughly O(N).
;; It may be slow, but with a good compiler at least it
;; doesn't waste much heap storage. :-)
(LET ((A (MAKE-ARRAY N)))
(DECLARE (DYNAMIC-EXTENT A))
(DOTIMES (I N)
(DECLARE (DYNAMIC-EXTENT I))
(SETF (AREF A I) (RANDOM (+ I 1))))
(AREF A M)))
(< (ZAP 5 3) 3) => T
- - - - - - - -
The following are in error, since the value of X is used outside of its
extent:
(LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
(PROGN (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)
NIL)
- - - - - - - -
Rationale:
This permits a programmer to offer advice to an implementation about
what may be stack-allocated for efficiency.
It may be difficult or impossible for a compiler to infer this
same information statically.
Since a number of implementations offer this capability and there
is demand from users for access to the capability, this ``codifies
existing practice.''
Because this approach is purely lexical, it does not interact badly with
other programs in the way that the macro WITH-DYNAMIC-EXTENT (see issue
by same name) would.
Current Practice:
Symbolics Genera and Symbolics Cloe offer stack allocation, though not
in this strategy.
[KMP thinks that] Lucid supports the proposal.
Cost to Implementors:
No cost is forced since implementations are permitted to simply
ignore the DYNAMIC-EXTENT declaration.
Cost to Users:
None. This change is upward compatible.
There may be some hidden costs to debugging using this declaration (or any
feature which permits the user to access dynamic extent objects without
the compiler proving that they are appropriate). If the user misdeclares
something and returns a pointer into the stack (or stores it in the heap),
an undefined situation may result and the integrity of the Lisp storage
mechanism may be compromised. Debugging these situations may be tricky,
but users who have asked for this feature have indicated a willingness
to deal with such costs. Nevertheless, the perils should be clearly
documented and casual users should not be encouraged to use this
declaration.
Cost of Non-Adoption:
Some portable code would be forced to run more slowly (due to
GC overhead), or to use non-portable language features.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This declaration allows a fairly low level optimization to work
by asking the user to provide only very high level information.
The alternatives (sharpsign conditionals, some of which may
lead to more bit-picky abstractions) are far less aesthetic.
Discussion:
A previous version of this proposal suggested primitives STACK-LET
and STACK-LET*. Consensus was that the more general declaration facility
would be more popular.
Pitman supports the DYNAMIC-EXTENT:NEW-DECLARATION.
Actually, a blurry issue is whether
(LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
=> 1
is well-defined. I refer to these stack-allocated things as being invalid
return values, but in fact we might want to say that they're ok to return
but that you just can't do any serious operations on them (ie, you can't
expect them to still be lists, etc.) Can anyone imagine a pointer into
unallocated stack causing problems for their GC? If so, we could be more
clear on this point.
The examples are tricky:
"I hope no one misreads the above as an argument that my proposal is too
complicated, since it does not derive at all from my proposal, but only
from the way Common Lisp works."
∂11-Jan-89 1522 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 15:21:22 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 15:17:08 PST
Date: 11 Jan 89 15:16 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DYNAMIC-EXTENT (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890111-151708-10854@Xerox>
I don't have the time to "wordsmith" this issue, but I think it
is important enough to bring before X3J13; I think the idea
in the proposal is fine, but I just clipped some of David's words
into the old one.
I'd like to release this in DRAFT form, I'm less sure what
we can vote on.
Opinions? Volunteers to edit this further?
!
Status: For Internal Discussion
Forum: CLEANUP
Issue: DYNAMIC-EXTENT
References: Scope and Extent
Category: ADDITION
Edit history: 27-Jun-88, Version 1 by Pitman (as issue STACK-LET)
15-Nov-88, Version 2 by Pitman (issue renamed, major revision)
11-Jan-89, Version 3 by Masinter (Moon's proposal)
Related-Issues: REST-ARGUMENT-EXTENT, WITH-DYNAMIC-EXTENT
Problem Description:
Sometimes a programmer knows that a particular data structure
will have only dynamic extent. In some implementations, it is
possible to allocate such structures in a way that will make them
easier to reclaim than by general purpose garbage collection
(eg, on the stack or in some temporary area). Currently, however,
there is no way to request the use of such an allocation mechanism.
Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):
Introduce a new declaration called DYNAMIC-EXTENT. The arguments to
this declaration are names of variables. The declaration asserts that
the value which is initially held by the indicated variable will have
dynamic extent. [In the case of an iteration variable, the declaration
asserts that on every iteration, the initial value of that variable
for the iteration will have dynamic extent.]
It is permissible for an implementation to simply ignore this declaration.
In implementations which do not ignore it, the compiler (or interpreter)
is free to make whatever optimizations are appropriate given this
information; the most common optimization is to stack-allocate the
initial value of the object. What data types (if any) can have dynamic
extent will can vary from implementation to implementation.
Since stack allocation of the initial value entails knowing at the
object's creation time that the object can be stack-allocated, it is
not generally useful to declare DYNAMIC-EXTENT for variables for
which have no lexically apparent initial value. For example,
(DEFUN F ()
(LET ((X (LIST 1 2 3)))
(DECLARE (DYNAMIC-EXTENT X))
...))
would permit those compilers which wish to do so to stack-allocate the
list in X. However,
(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
(DEFUN F () (G (LIST 1 2 3)))
could not typically permit a similar optimization in G because it would
be a modularity violation for the compiler to assume facts about G from
within F. Only an implementation which was willing to be responsible for
recompiling F if G's definition changed incompatibly could stack-allocate
the list argument to G in F.
Other interesting cases are:
(PROCLAIM '(INLINE G))
(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
(DEFUN F () (G (LIST 1 2 3)))
and (DEFUN F ()
(FLET ((G (X) (DECLARE (DYNAMIC-EXTENT X)) ...))
(G (LIST 1 2 3))))
where some compilers might realize the optimization was possible and others
might not.
An interesting variant of this is the so-called `stack allocated rest list'
which can be achieved (in implementations supporting the optimization) by:
(DEFUN F (&REST X)
(DECLARE (DYNAMIC-EXTENT X))
...)
Note here that although the initial value of X is not explicit, the F
function is responsible for assembling the list X from the passed arguments,
so the F function can be optimized by the compiler to construct a
stack-allocated list instead of a heap-allocated list in implementations
which support such.
The meaning of a dynamic extent declaration is that execution of the
forms in the scope of the declaration will not "save" any "proper part"
of the initial value of the declared variable. To "save" an object
means to cause a reference to that object to be accessible outside the
dynamic extent of the form at the beginning of whose body the
declaration appears. An object can be "saved" by storing it with a
side-effecting operation and not replacing it with a different value
before the end of the dynamic extent, by using it as a component of a
freshly-allocated object that is itself "saved," by capturing it in a
function closure that is itself "saved," by returning it as a value, or
by transmitting it outside the dynamic extent with THROW. A "proper
part" of an object A is any object that is accessible at the beginning
of the scope of the declaration -only- by applying a function to A or to
a "proper part" of A. This means that any objects freshly allocated
during the construction of the initial value of the declared variable,
and not "saved" during the construction of that value, are "proper
parts" and can be allocated on a stack.
Examples:
In
(LET ((X (LIST 'A1 'B1 'C1))
(Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
(DECLARE (DYNAMIC-EXTENT X Y))
...)
The "proper parts" of X are three conses, and the "proper parts" of Y
are three other conses. None of the symbols A1, B1, C1, A2, B2, C2, or
NIL is a "proper part" of X or Y. However, if a freshly allocated
uninterned symbol had been used, it would have been a "proper part."
- - - - - - - -
(DOTIMES (I N)
(DECLARE (DYNAMIC-EXTENT I))
This is particularly instructive. Since I is an integer by the
definition of DOTIMES, but EQ and EQL are not necessarily equivalent for
integers, what are the "proper parts" of I, which this declaration
requires the body of the DOTIMES not to "save"? If the value of I is 3,
and the body does (SETQ FOO 3), is that an error? The answer is no, but
the interesting thing is that it depends on the implementation-dependent
behavior of EQ on numbers. In an implementation where EQ and EQL are
equivalent for 3, then 3 is not a "proper part" because (EQ I (+ 2 1))
is true, and therefore there is another way to access the object besides
going through I. On the other hand, in an implementation where EQ and
EQL are not equivalent for 3, then the particular 3 that is the value of
I is a "proper part", but any other 3 is not. Thus (SETQ FOO 3) is valid
but (SETQ FOO I) is erroneous. Since (SETQ FOO I) is erroneous in some
implementations, it is erroneous in all portable programs, but some other
implementations may not be able to detect the error.
- - - - - - - -
(LET ((X (LIST 1 2 3)))
(DECLARE (DYNAMIC-EXTENT X))
(PRINT X)
NIL)
PRINT does not "save" any part of its input.
This prints (1 2 3)
- - - - - - - -
(DO ((L (LIST-ALL-PACKAGES) (CDR L)))
((NULL L))
(DECLARE (DYNAMIC-EXTENT L))
(PRINT (CAR L)))
prints all packages; none of the newly-allocated list structures are saved.
- - - - - - - -
(DEFUN ADD (&REST X) (DECLARE (DYNAMIC-EXTENT X)) (APPLY #'+ X))
(ADD 1 2 3) => 6
I.e., useful way to declare that &REST lists have dynamic extent
- - - - - - - -
(DEFUN ZAP (X Y Z)
(DO ((L (LIST X Y Z) (CDR L)))
((NULL L))
(DECLARE (DYNAMIC-EXTENT L))
(PRIN1 (CAR L))))
(ZAP 1 2 3)
prints 123
- - - - - - - -
(DEFUN ZAP (N M)
;; Computes (RANDOM (+ M 1)) at relative speed of roughly O(N).
;; It may be slow, but with a good compiler at least it
;; doesn't waste much heap storage. :-)
(LET ((A (MAKE-ARRAY N)))
(DECLARE (DYNAMIC-EXTENT A))
(DOTIMES (I N)
(DECLARE (DYNAMIC-EXTENT I))
(SETF (AREF A I) (RANDOM (+ I 1))))
(AREF A M)))
(< (ZAP 5 3) 3) => T
- - - - - - - -
The following are in error, since the value of X is used outside of its
extent:
(LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
(PROGN (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)
NIL)
- - - - - - - -
Rationale:
This permits a programmer to offer advice to an implementation about
what may be stack-allocated for efficiency.
It may be difficult or impossible for a compiler to infer this
same information statically.
Since a number of implementations offer this capability and there
is demand from users for access to the capability, this ``codifies
existing practice.''
Because this approach is purely lexical, it does not interact badly with
other programs in the way that the macro WITH-DYNAMIC-EXTENT (see issue
by same name) would.
Current Practice:
Symbolics Genera and Symbolics Cloe offer stack allocation, though not
in this strategy.
[KMP thinks that] Lucid supports the proposal.
Cost to Implementors:
No cost is forced since implementations are permitted to simply
ignore the DYNAMIC-EXTENT declaration.
Cost to Users:
None. This change is upward compatible.
There may be some hidden costs to debugging using this declaration (or any
feature which permits the user to access dynamic extent objects without
the compiler proving that they are appropriate). If the user misdeclares
something and returns a pointer into the stack (or stores it in the heap),
an undefined situation may result and the integrity of the Lisp storage
mechanism may be compromised. Debugging these situations may be tricky,
but users who have asked for this feature have indicated a willingness
to deal with such costs. Nevertheless, the perils should be clearly
documented and casual users should not be encouraged to use this
declaration.
Cost of Non-Adoption:
Some portable code would be forced to run more slowly (due to
GC overhead), or to use non-portable language features.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This declaration allows a fairly low level optimization to work
by asking the user to provide only very high level information.
The alternatives (sharpsign conditionals, some of which may
lead to more bit-picky abstractions) are far less aesthetic.
Discussion:
A previous version of this proposal suggested primitives STACK-LET
and STACK-LET*. Consensus was that the more general declaration facility
would be more popular.
Pitman supports the DYNAMIC-EXTENT:NEW-DECLARATION.
Actually, a blurry issue is whether
(LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
=> 1
is well-defined. I refer to these stack-allocated things as being invalid
return values, but in fact we might want to say that they're ok to return
but that you just can't do any serious operations on them (ie, you can't
expect them to still be lists, etc.) Can anyone imagine a pointer into
unallocated stack causing problems for their GC? If so, we could be more
clear on this point.
The examples are tricky:
"I hope no one misreads the above as an argument that my proposal is too
complicated, since it does not derive at all from my proposal, but only
from the way Common Lisp works."
∂11-Jan-89 1534 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 15:33:53 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 15:32:33 PST
Date: 11 Jan 89 15:32 PST
From: masinter.pa@Xerox.COM
Subject: Issue: EXIT-EXTENT (Version 6)
To: cl-cleanup@sail.stanford.edu
Message-ID: <890111-153233-10914@Xerox>
N EXIT-EXTENT:MINIMAL
Y EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
Reason: MEDIUM provides more useful semantics in one important case: if
an application has a top-level catch tag, and a cleanup handler does a
(throw 'top-level ...) while cleaning up during such a throw. Lack of
these semantics in Maclisp results in problems in Multics Emacs, whose
error handler prints a minibuffer message and then throws to the top
level, but if an error happens during a cleanup, the top-level catch is
no longer available, resulting in an infinite loop of "throw to
nonexistent tag" errors. This seems like it would be a common paradigm,
but unless there is a way for a cleanup handler to determine the context
of its invocation, MINIMAL makes this non-portable.
∂11-Jan-89 1558 CL-Cleanup-mailer Re: Issue: EXIT-EXTENT (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 15:58:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 15:52:48 PST
Date: 11 Jan 89 15:52 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXIT-EXTENT (Version 6)
In-reply-to: masinter.pa's message of 11 Jan 89 15:32 PST
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890111-155248-10971@Xerox>
That message should have been marked "From: Barmar@think.com"
∂11-Jan-89 1601 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 5)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 16:01:10 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA11476; Wed, 11 Jan 89 16:02:34 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA19952; Wed, 11 Jan 89 15:58:45 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA02137; Wed, 11 Jan 89 15:59:45 PST
Date: Wed, 11 Jan 89 15:59:45 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901112359.AA02137@clam.sun.com>
To: cperdue@Sun.COM, masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-SUB-METHODS (Version 5)
Cc: cl-cleanup@sail.stanford.edu, jonl@lucid.com
> I believe that this will get voted on at this meeting unless there is a
> successful motion to table it.
If so I'll vote against but with willingness to reconsider,
especially if the proposal can be stated much more simply.
∂11-Jan-89 1614 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 9)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 11 Jan 89 16:13:07 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08811; 11 Jan 89 23:55 GMT
Date: Wed, 11 Jan 89 23:58:03 GMT
Message-Id: <18529.8901112358@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Moon@scrc-stony-brook.arpa
In-Reply-To: Kent M Pitman's message of Wed, 11 Jan 89 12:20 EST
Cc: CL-Cleanup@sail.stanford.edu
> Btw, I spoke last week on the phone to Jonathan Rees about this. He's not
> yet gotten around to sending mail but he said...
> - he doesn't think the ALLOW proposal is a good idea
> - the ALLOW proposal is inconsistent with the proposal in
> SYMBOL-MACROLET-SEMANTICS
> He hadn't seen the actual LEXICAL proposal yet, but from my description
> of the differences, he seemed pretty firm on the idea that it was the
> right idea.
I agree. The SYMBOL-MACROLET proposal expalins type declarations as
equiv to adding THE <type> to the expansion; and that's also the
explanation for LEXICAL. I support both. And votes on these issues
should at least be consistent.
∂11-Jan-89 1652 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 2)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Jan 89 16:51:54 PST
Received: by ti.com id AA12442; Wed, 11 Jan 89 18:51:07 CST
Received: from Kelvin by tilde id AA06197; Wed, 11 Jan 89 18:35:47 CST
Message-Id: <2809557489-5434538@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 11 Jan 89 18:38:09 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Robert A. Cassels" <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@Sail.Stanford.EDU
Subject: Re: Issue: REAL-NUMBER-TYPE (version 2)
In-Reply-To: Msg of Sun, 8 Jan 89 11:29 EST from Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
> Proposal (REAL-NUMBER-TYPE:REAL):
>
> Add a standard type specifier
> (REAL low high)
> which means
> (OR (RATIONAL low high) (FLOAT low high))
...
> Proposal (REAL-NUMBER-TYPE:REALP):
>
> Add a specific data type predicate REALP which tests for membership in
> this type. [By analogy with NUMBERP.]
...
> Current Practice:
>
> Probably nobody does this.
Actually, both the REAL type and REALP predicate are already supported on the
TI Explorer and LMI Lambda.
∂11-Jan-89 1722 CL-Cleanup-mailer Re: Issue: REAL-NUMBER-TYPE (version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Jan 89 17:22:44 PST
Received: by ti.com id AA12536; Wed, 11 Jan 89 19:20:41 CST
Received: from Kelvin by tilde id AA06891; Wed, 11 Jan 89 19:15:14 CST
Message-Id: <2809559853-5576593@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 11 Jan 89 19:17:33 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: Cassels@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: REAL-NUMBER-TYPE (version 1)
In-Reply-To: Msg of Mon, 9 Jan 89 08:38 EST from "Steve Bacher (Batchman)" <SEB1525@draper.com>
> Hold on. How should the following be handled:
> (declare (type (real 3.1415926 71/7) x))
> ...or (typep x '(real 3.1415926 71/7))?
> When the type determination is made, how is the coercion of x to be done?
> Must x be coerced from rational to float, or from float to rational, in
> order to do the type check? Should RATIONAL or RATIONALIZE be used? ETc.,
> etc., etc.
On the Explorer, (TYPEP X '(REAL 3.1415926 71/7)) is expanded by the
compiler to (AND (REALP X) (>= X 3.1415926) (<= X 71/7)) and then follows
the normal rules for numerical comparison from there.
∂11-Jan-89 1750 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Jan 89 17:50:21 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04314g; Wed, 11 Jan 89 17:46:15 PST
Received: by bhopal id AA07016g; Wed, 11 Jan 89 17:48:32 PST
Date: Wed, 11 Jan 89 17:48:32 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901120148.AA07016@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@Sail.Stanford.Edu
In-Reply-To: masinter.pa@Xerox.COM's message of 11 Jan 89 14:47 PST <890111-144755-10740@Xerox>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
re: As I think about it, I'm not sure why we rule out the possibility that the
upgrading of arrays might happen differently for different arrays: for
example, I might have an algorithm that "upgraded" all simple
non-adjustable arrays with ARRAY-TOTAL-SIZE less than 2 to ELEMENT-TYPE T,
but be more strict about larger arrays.
Lucid would certainly oppose that change. Our compiler optimizations
work on simple-arrays of known element type; and good reasons exist
as to why the simple/non-simple distinction and the element-type
distinctions are important (other "stock hardware" implmentations
have similar open-coding techniques). I see no benefit to further
discrimination based on rank or array total size.
-- JonL --
∂11-Jan-89 1812 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89 18:12:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 519869; Wed 11-Jan-89 21:09:25 EST
Date: Wed, 11 Jan 89 21:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
To: masinter.pa@Xerox.COM
cc: Jon L White <jonl@lucid.com>, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <890111-144755-10740@Xerox>
Message-ID: <19890112020914.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 11 Jan 89 14:47 PST
From: masinter.pa@Xerox.COM
....
As I think about it, I'm not sure why we rule out the possibility that the
upgrading of arrays might happen differently for different arrays: for
example, I might have an algorithm that "upgraded" all simple
non-adjustable arrays with ARRAY-TOTAL-SIZE less than 2 to ELEMENT-TYPE T,
Actually you couldn't do that, because Common Lisp mandates the separate
existence of strings and bit-vectors. But we get the idea.
but be more strict about larger arrays. The major part of the proposal
("Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is not
*, to be true if and only if <x> is an array that could be the result of
giving <type> as the :element-type argument to MAKE-ARRAY.") could be kept,
No, because you would have to say what the other arguments to MAKE-ARRAY were.
If you can prove that the statement I just said is false, then I will change
my mind and agree with you, since it would considerably simplify the proposal.
I spent some time just now unsuccessfully trying to prove that the statement
is true. The place to think about is SUBTYPEP.
and the part that talks about upgrading (Clarify that "upgrading" implies a
movement upwards in the type- hierarchy lattice.) would just have to be
recast in terms of a specific array.
This is counter to the part that says "Clarify that upgrading an array
element-type is independent of any
other property of arrays, such as rank, adjustability, fill-pointers,
displacement etc."
but I wonder now if that is a clarification -- is it a Change? -- and if it
is necessary.
You're probably right that it is a change, although I think JonL was
unable to find any current practice that it contradicts.
∂11-Jan-89 1821 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (Version 7)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 18:21:40 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA14739; Wed, 11 Jan 89 18:22:25 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA25540; Wed, 11 Jan 89 18:19:03 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA08867; Wed, 11 Jan 89 18:21:44 PST
Message-Id: <8901120221.AA08867@denali.sun.com>
To: masinter.pa@Xerox.COM
Cc: Jon L White <jonl@lucid.com>
Cc: barmar@Think.COM, CL-CLEANUP@sail.stanford.edu
Subject: Re: Issue: DEFPACKAGE (Version 7)
In-Reply-To: Your message of 06 Jan 89 23:47:00 -0800;
<890106-234746-2045@Xerox> .
Date: Wed, 11 Jan 89 18:21:37 PST
From: peck@Sun.COM
>After re-reading the discussion, I think the only issue is to define
>explicitly what "at variance with the current state of that package" means.
I'd like to make sure that it is possible to define mutually
dependent packages using DEFPACKAGE.
What i envision is using TWO passes with DEFPACKAGE for each package.
The first pass defines symbols that are interned (home-package) in that package,
ie, using :SHADOW, :INTERN, :EXPORT
and a second pass which enables access to symbols homed in other packages
ie, using :SHADOWING-IMPORT-FROM, :USE, :IMPORT-FROM,
and possibly :EXPORT them to users of this package
Yes, i have seen applications where this is used and useful.
This disciplined used of two DEFPACKAGE forms on the same package
should enable creating the desired package and symbol-inheritance structure.
Doing this with two DEFPACKAGE forms should not produce any state
which is "at variance" with the state of the package, no?
For example of a small fragment:
(DEFPACKAGE main ; pass 1, intern symbols homed in MAIN and UTIL
(:export 'main1)) ; for :USE and :IMPORT-FROM
(DEFPACKAGE util
(:export 'util1)) ; create and export to USEr's of util
(DEFPACKAGE util ; pass 2, now import or otherwise inherit symbols
(:import-from main 'main1) ; inherit main:main1
; for programmers in-package UTIL
(DEFPACKAGE main
(:use 'util) ; programmers in MAIN will want access to all UTIL:syms
(:export 'util)); USEr's of MAIN will expect access to UTIL1.
; and may not even know of package UTIL!
I strongly support the view that DEFPACKAGE should be constructed
out of the existing primitives, and let the concept of "at variance"
be determined by when those primitives detect incompatible package changes.
[it is true that in this example the two forms for (DEFPACKAGE util...)
could be coalesced into one.]
∂11-Jan-89 1928 CL-Cleanup-mailer Issue: DEFPACKAGE (Version 7)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Jan 89 19:27:55 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04418g; Wed, 11 Jan 89 19:22:25 PST
Received: by bhopal id AA07308g; Wed, 11 Jan 89 19:24:39 PST
Date: Wed, 11 Jan 89 19:24:39 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901120324.AA07308@bhopal>
To: masinter.pa@Xerox.COM
Cc: barmar@Think.COM, CL-CLEANUP@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 23:47 PST <890106-234746-2045@Xerox>
Subject: Issue: DEFPACKAGE (Version 7)
re A DEFPACKAGE is "at variance with the current state of a pre-existing
package" if the result of executing the DEFPACKAGE with a different name
would create a package with a different set of exported symbols, a
different set of USEd packages, with any *more* shadowing symbols, or a
different set of nicknames.
A DEFPACKAGE is not at variance with the current state of a pre-existing
package even if the size of the pre-existing package differs from the :SIZE
of the DEFPACKAGE form, or if it the pre-existing package has more internal
symbols.
The second paragraph is fine. The first is questionable. I think the
only way to say it is that a DEFPACKAGE form is "at variance" with an
existing package (of the specified name) if any of the following holds:
(1) the set of used packages specified by the form is different from
that of the existing package;
(2) the set of nicknames specified by the form is different from
that of the existing package;
(3) the set of exported symbols specified ... ;
(4) the set of shadowing symbols specified ... ;
(5) the set of "foreign" symbols specified ... ; [I will use "foreign"
here to mean a symbol present in a package, but "homed" in some
other package; these are created via :IMPORT-FROM etc.]
[I hope this is clear enough, and we don't have to explain what it
means for "the set of used packages" to be different!!!]
Perhaps a better alternative is to give a standard canonical macro-
expansion of DEFPACKAGE into calls on existing functions (such as EXPORT,
FIND-SYMBOL, etc). This is perfectly doable now, since the proposal
fully specifies ordering constraints for the subparts that matter.
Of course, an implementation wouldn't be required to use that canonical
expansion, but the semantics would be required to be the same. The
advantage of this is that it allows for redefinitions using the already
existing notions of name-conflicts etc, without having to specify that
every possible significant change has "undefined" consequences.
Tactical point: we are nearing the wire for having presentable
proposals. Some of the feedback of the past two weeks seems reasonable
to incorporate and some of it is "unclear" (to say the least). Do
you really want to tinker with the wording of any issue already mailed
out between now and net Tuesday? I would think the safer thing to do
would be to collect a bunch of "amendments" and bring them to the
meeting. There are probably two dozen minor, non-controversial
amendments, and maybe two or three majorly controversial ones. But
I'm leary of us "digging a hole" similar to the one opened up at the
very last minute on DECLARE-TYPE-FREE.
-- JonL --
∂11-Jan-89 1957 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Jan 89 19:49:29 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04432g; Wed, 11 Jan 89 19:44:42 PST
Received: by bhopal id AA07369g; Wed, 11 Jan 89 19:47:00 PST
Date: Wed, 11 Jan 89 19:47:00 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901120347.AA07369@bhopal>
To: barmar@Think.COM
Cc: KMP@stony-brook.scrc.symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 10 Jan 89 18:48 EST <19890110234853.0.BARMAR@OCCAM.THINK.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST
re: We know that because we understand how Lisp
differentiates between a structured object and its contents, but most
traditional languages don't make such a distinction, so I think it is
important that the CL standard not presume this abstract understanding.
I agree with you here. And I don't think it is that painful to be
correct and exact in the specification.
-- JonL --
∂11-Jan-89 1957 CL-Cleanup-mailer Possible issue: GCD-NO-ARGUMENTS
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Jan 89 19:57:48 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04451g; Wed, 11 Jan 89 19:53:31 PST
Received: by bhopal id AA07394g; Wed, 11 Jan 89 19:55:47 PST
Date: Wed, 11 Jan 89 19:55:47 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901120355.AA07394@bhopal>
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Cc: cl-cleanup@sail.stanford.edu, gls@think.com,
richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
In-Reply-To: Jeff Dalton's message of Tue, 10 Jan 89 23:37:00 GMT <15927.8901102337@subnode.aiai.ed.ac.uk>
Subject: Possible issue: GCD-NO-ARGUMENTS
The LCM issue even appeared on Guy's "Clarifications" of 6-Dec-85".
Tobin's reasoning about GCD looks ok to me, but it might not be that
bad simply to say that 0 is a singluar point for GCD.
Not too long ago, I proposed adding rational infinities to CL (to the
general common-lisp mailing list, I think, rather than to Cl-cleanup);
by analogy to IEEE floating infinities, we could have -1/0 and 1/0 as
rational infinities. There are a number of other reasons for wanting
these objects besides (GCD 0).
-- JonL --
∂11-Jan-89 2007 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 2)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 89 20:07:01 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA16343@EDDIE.MIT.EDU>; Wed, 11 Jan 89 22:36:07 EST
Received: by spt.entity.com (smail2.5); 11 Jan 89 22:17:19 EST (Wed)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 11 Jan 89 15:16 PST <890111-151708-10854@Xerox>
Subject: Issue: DYNAMIC-EXTENT (Version 2)
Message-Id: <8901112217.AA15621@spt.entity.com>
Date: 11 Jan 89 22:17:19 EST (Wed)
From: gz@spt.entity.com (Gail Zacharias)
Actually, a blurry issue is whether
(LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
=> 1
is well-defined. I refer to these stack-allocated things as being invalid
return values, but in fact we might want to say that they're ok to return
but that you just can't do any serious operations on them (ie, you can't
expect them to still be lists, etc.) Can anyone imagine a pointer into
unallocated stack causing problems for their GC? If so, we could be more
clear on this point.
Yes, this would lose badly in our system if the outer call to LIST were to gc.
It's not pointing into unallocated stack that's the problem, it's pointing to
reallocated stack.
∂11-Jan-89 2016 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 11 Jan 89 20:16:35 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 258908; Wed 11-Jan-89 23:12:43 EST
Date: Wed, 11 Jan 89 23:12 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
To: jonl@lucid.com, masinter.pa@Xerox.COM
cc: cl-cleanup@Sail.Stanford.Edu
In-Reply-To: <8901120148.AA07016@bhopal>
Message-ID: <19890112041220.9.GSB@GANG-GANG.SCRC.Symbolics.COM>
Date: Wed, 11 Jan 89 17:48:32 PST
From: Jon L White <jonl@lucid.com>
re: As I think about it, I'm not sure why we rule out the possibility that the
upgrading of arrays might happen differently for different arrays: for
example, I might have an algorithm that "upgraded" all simple
non-adjustable arrays with ARRAY-TOTAL-SIZE less than 2 to ELEMENT-TYPE T,
but be more strict about larger arrays.
Lucid would certainly oppose that change. Our compiler optimizations
work on simple-arrays of known element type; and good reasons exist
as to why the simple/non-simple distinction and the element-type
distinctions are important (other "stock hardware" implmentations
have similar open-coding techniques). I see no benefit to further
discrimination based on rank or array total size.
-- JonL --
Right. If you can't determine the upgraded type from a declaration, the
declaration is next to useless. (It just is not reasonable to have to,
for instance, know the size of an array in order to be able to determine
how to access it.)
∂11-Jan-89 2138 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 21:37:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 21:36:44 PST
Date: 11 Jan 89 21:34 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Wed, 11 Jan 89
17:48:32 PST
To: Jon L White <jonl@lucid.com>
cc: Masinter.pa@Xerox.COM, cl-cleanup@Sail.Stanford.Edu
Message-ID: <890111-213644-11560@Xerox>
JonL, I was not suggesting a requirement that implementors would have to
upgrade different arrays differently. Why would Lucid oppose allowing other
implementors to take a different implementation strategy? Certainly your
compiler optimizations could continue to work based on your assertions
about your own array implementation types.
> but be more strict about larger arrays. The major part of the
proposal
> ("Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is
not
> *, to be true if and only if <x> is an array that could be the result
of
> giving <type> as the :element-type argument to MAKE-ARRAY.") could be
kept,
>
>No, because you would have to say what the other arguments to MAKE-ARRAY
were.
>
>
You know what the other arguments to MAKE-ARRAY are by looking at <x>.
Imagine:
Implementation A upgrades integer ranges to (SIGNED-BYTE n) for n a power
of 2 up to 32, and then T.
Implementation B upgrades integer ranges to (SIGNED-BYTE 32) and then to T.
Implementation C upgrades simple small (say, less than total-size 2) arrays
like B, and other arrays like A.
You can implement (C:TYPEP object type) by (if (simple-small-p object)
(b:typep object type) (a:typep object type)). I.e., TYPEP need not merely
be implemented by ARRAYP + a test on ARRAY-ELEMENT-TYPE.
∂11-Jan-89 2148 CL-Cleanup-mailer New versions vs amendments
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 21:48:16 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 21:46:41 PST
Date: 11 Jan 89 21:45 PST
From: masinter.pa@Xerox.COM
Subject: New versions vs amendments
In-reply-to: Jon L White <jonl@lucid.com>'s message of Wed, 11 Jan 89
19:24:39 PST
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, barmar@Think.COM, CL-CLEANUP@sail.stanford.edu
Message-ID: <890111-214641-11567@Xerox>
The problem with DECLARE-TYPE-FREE is that people only had a chance to see
the "wrong" version. If there are issues that have been released, and we
think we will want to amend them, we can bring along copies of the
amended/edited issues; I think it will actually make it easier than trying
to edit them on the fly.
Better still would be to have the amendment *and* the amended version. I
think that would allow people who made up their mind about an earlier
version to see what was different.
We also have to be more conservative about wording changes to minimize the
differences.
∂11-Jan-89 2222 CL-Cleanup-mailer Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 22:22:27 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 22:21:18 PST
Date: 11 Jan 89 22:20 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
In-reply-to: David N Gray <Gray@DSG.csc.ti.com>'s message of Tue, 3 Jan 89
10:46:29 CST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890111-222118-11592@Xerox>
I hadn't given much thought to this issue before. In Medley, we represented
"unspecific" components by the empty string.
I.e., "foo." => (host nil device nil directory nil name "foo" type ""
version nil),
while "foo" => (host nil device nil directory nil name "foo" type nil
version nil).
Why do you need a separate keyword?
∂12-Jan-89 0033 CL-Cleanup-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 00:33:05 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 00:31:54 PST
Date: 12 Jan 89 00:30 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: cl-cleanup@sail.stanford.edu
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Message-ID: <890112-003154-11895@Xerox>
[lmm: from Ballot]
I can understand why someone might find the need for :UNSPECIFIC
in Unix unclear, but I think that is because it is not clear what
filenames would be parsed as pathnames with :UNSPECIFIC type [*];
:UNSPECIFIC is nonetheless useful for building pathnames directly
when you know which case you want and need a way to specify it.
[*] Does a name without "." parse as type NIL or :UNSPECIFIC?
Different Unix programs use different conventions. Some are
willing to merge in a type field, others, such as the C compiler,
leave names as-is. So the "right" answer may vary.
∂12-Jan-89 0037 CL-Cleanup-mailer Issue: PROCLAIM-SPECIAL (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 00:37:52 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 00:34:46 PST
Date: 12 Jan 89 00:34 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: PROCLAIM-SPECIAL (Version 9)
To: cl-cleanup@sail.stanford.edu
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
line-fold: NO
Message-ID: <890112-003446-11899@Xerox>
[From Ballot]
Under this proposal, special proclamations establish a default for
a name but, because of the lexical declaration, no longer force it
to be special everywhere. It also allows the programmer to say
that a global name is intended as a variable (i.e., references to
it are not spelling mistakes) without proclaiming it special. I
think these are important changes that should be preserved even if
this proposal fails. Another important feature is that LG references
to global variables can be fast in deep-bound implementations (since
L "searches" can be compiled away) while DG references (the only
global variables we have now) first have to look in D. Finally,
the current semantics are subtly confusing, because the specialness
of global variables occasionally shows through. For all of these
reasons, I support this proposal.
I think the most controversial change is the introduction of a
separate global environment, where before the only globals were
effectively just the global end of the dynamic env. Most of the
implementation complexity stems from this change, and it is likely
that it lies behind most objections.
A reasonable fallback, if this proposal does not pass, would be
to say that variables that are proclaimed lexical can never by
given dynamic bindings. That is, the global value would be taken
after searching L or D but not both and so would effectively be
an extension of the L or D env, case by case. This would be
somewhat unfortunate, because local lexical bindings for names
proclaimed special would still make sense (because they could be
declared lexical) but we wouldn't allow local special declarations
for names proclaimed lexical. The full proposal is better.
∂12-Jan-89 0048 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 00:48:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 00:45:14 PST
Date: 12 Jan 89 00:44 PST
From: masinter.pa@Xerox.COM
Subject: Issue: TAGBODY-CONTENTS (Version 5)
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
message of Thu, 12 Jan 89 03:57:03 GMT
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890112-004514-11904@Xerox>
On your ballot, you said:
"Contents should be valid forms (including self-evaluating) or valid tags.
Duplicate tags should be an error (as in the proposal)."
However, the EVAL-OTHER proposal passed at the last meeting makes all
"other" objections self-evaluating.
∂12-Jan-89 0309 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Jan 89 03:09:23 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04762g; Thu, 12 Jan 89 03:05:07 PST
Received: by bhopal id AA01044g; Thu, 12 Jan 89 03:07:24 PST
Date: Thu, 12 Jan 89 03:07:24 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901121107.AA01044@bhopal>
To: Gray@DSG.csc.ti.com
Cc: masinter.pa@Xerox.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: David N Gray's message of Wed, 11 Jan 89 10:10:01 CST <2809527001-3602765@Kelvin>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
re: [JonL] I would go for a version that treated an inner declaration
as if it were the intersection of the outter one. How about you?
[Gray] Agreed. That's what version 6 of DECLARE-TYPE-FREE said:
Clarify that if nested type declarations refer to the same variable,
then the value of the variable must be a member of the intersection of
the declared types.
Version 2 (but not Version 1) also had that phraseology in it. Looks
like that paragraph fell into "Masinter's Hole" (that's the hole that
Larry said he hoped he wouldn't dig himself into when he began tinkering
with it late at night, just before Releasing it to X3J13). Probably Moon
lost track of it when he added the LEXICAL proposal (i.e., trying to fill
in the "Hole").
We definitely need that phrase.
-- JonL --
∂12-Jan-89 0420 CL-Cleanup-mailer Issue: DEFPACKAGE (Version 7)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Jan 89 04:20:19 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04802g; Thu, 12 Jan 89 04:14:35 PST
Received: by bhopal id AA01212g; Thu, 12 Jan 89 04:16:52 PST
Date: Thu, 12 Jan 89 04:16:52 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901121216.AA01212@bhopal>
To: peck@Sun.COM
Cc: masinter.pa@Xerox.COM, barmar@Think.COM, CL-CLEANUP@sail.stanford.edu
In-Reply-To: peck@Sun.COM's message of Wed, 11 Jan 89 18:21:37 PST <8901120221.AA08867@denali.sun.com>
Subject: Issue: DEFPACKAGE (Version 7)
Here's an excerpt from Version 7:
It is noted that DEFPACKAGE cannot be used to create two "mutually
recursive" packages, such as:
(defpackage my-package
(:use lisp your-package) ;requires 'your-package' to exist first
(:export "MY-FUN"))
(defpackage your-package
(:use lisp)
(:import-from my-package "MY-FUN") ;requires 'my-package' to exist first
(:export "MY-FUN"))
However, nothing prevents one from using the package-effecting functions
such as USE-PACKAGE, IMPORT, and EXPORT to establish such links (which
ought to be very rare) after a more standard use of DEFPACKAGE.
The problem is similar to "defining" a circular list; typically you
have to start out with a non-circular "definition" [e.g., such as
by (CONS 'A NIL)] and then make a circularizing step [e.g., such as
(RPLACD X X)].
Your two-pass approach would *probably* work in many reasonable
implementations, even though the two passes would be "at variance"
by the definitions given previously. The problem still seems to
be that we "ran out of time" before agreeing on how to reconcile
two defpackage calls that weren't basically the same.
-- JonL --
∂12-Jan-89 0520 CL-Cleanup-mailer ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Jan 89 05:20:12 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04822g; Thu, 12 Jan 89 05:16:01 PST
Received: by bhopal id AA01326g; Thu, 12 Jan 89 05:18:18 PST
Date: Thu, 12 Jan 89 05:18:18 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901121318.AA01326@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 12 Dec 88 18:16 PST <881212-181649-5908@Xerox>
Subject: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
This ballot represents the consensus of senior "wizards" at Lucid; we
hope the information helps in deciding what issues to "bundle" together.
We recognize this ballot as a "straw poll" rather than an official X3
ballot; our official votes will be given in the ususal channels (e.g.,
by Dick or myself at the X3J13 meeting), most likely along the lines
indicated below.
-- JonL --
Y ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
Y ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
Y CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Version 5, 5-Dec-88, Mailed 5 Dec 88
Y CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
Y DECLARATION-SCOPE:NO-HOISTING
Y DECLARATION-SCOPE:LIMITED-HOISTING
Version 4, 15-Nov-88, Mailed 9-Dec-88
Y DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Version 4, 5-Dec-88, Mailed 5-Dec-88
N DECLARE-TYPE-FREE:ALLOW
Version 8, 7-Dec-88, Mailed 9-Dec-88
We wish to vote yes on a corrected, extended version of "LEXICAL"
Y DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
Y DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
Y DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
Y DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
Y DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
And we think there should be a more detailed explanation of
why the current state has a problem.
N DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
N DESCRIBE-INTERACTIVE:NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
Y DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
N EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
N EXIT-EXTENT:MINIMAL
N EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
[I think we felt that the current vague state is better than
a muddled attempt to fix it; we are currently in the process of
doing extensive work on this question for QLISP -- JonL --]
Y EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
N FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
N FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Version 4, 7-Dec-88, Mailed 12-Dec-88
We feel that fixnums could be made portably useful only if they were
required to be large enough to cover both array indices and object
counts; neither proposal is strong enough about these points.
Y FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
Y FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
N FUNCTION-COMPOSITION:NEW-FUNCTIONS
N FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
N FUNCTION-DEFINITION:FUNCTION-SOURCE
Version 2, 09-Dec-88 , Mailed 9 Dec 88
The name FUNCTION-SOURCE sounds too much like a source-file facility
[Lucid has such a thing]. We might accept the proposal if the name
were SOURCE-CODE; unfortunately, though this is in Lucid's documentation,
we are not really happy with that name either.
Y FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
Y FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
Y GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
Y HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Version 7, 8-Dec-88, Mailed 9-Dec-88
And fix the typo in the example.
Y HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
Y HASH-TABLE-TESTS:ADD-EQUALP
Version 2, 8-Dec-88, Mailed 8 Dec 88
Y IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
N LAMBDA-FORM:NEW-MACRO
Version 4, 22-Nov-88, Mailed 8-Dec-88
Y LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
N LISP-SYMBOL-REDEFINITION:DISALLOW
Version 5, 22-Nov-88, Mailed 8 Dec 88
We prefer a much simpler statement, such as "Redefining any documented
definition on a symbol in the LISP package -- such as variables,
functions, constants, properties and property-lists, etc -- is
undefined, except for the explicitly allowed cases (e.g. dynamic
binding of variables)."
Y MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
Y MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
N NTH-VALUE:ADD
Version 4, 8-Dec-88, Mailed 8 Dec 88
Y PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
Y PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
Y PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Version 1 27-Jun-88, Mailed 7 Oct 88
But the Cost to Implementors is wrong -- it will cost us something.
Y PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
But we feel that the proposal could be reduced from three pages
to three sentences.
Y PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
N PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
We could only accept this if it is clearly spelled out that it is
an error to make a dynamic binding of a proclaimed lexical variable;
we could not find such a statement in the proposal.
Y RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Version 3, 9-Oct-88, Mailed 14-Oct-88
Y RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
A REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
[This is not a "dont care"; we were unable to decide what to do. --JonL --]
Y REST-LIST-ALLOCATION:NEWLY-ALLOCATED
N REST-LIST-ALLOCATION:MAY-SHARE
N REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
We "buy" Will Clinger's argument about the semantics of APPLY.
Y RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
N ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
We do not feel that ROOM is so much different than any other function
which has optional arguments; perhaps a much more general proposal is
called for that would address the question of "explicitly" not supplying
optional and keyword arguments.
[The following are mutually exclusive]
I SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
Y SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
We could live with either proposal; however the earlier one fails to
address several necessary issues of cleanup for the CLOS document; it
would be acceptable to us if it simply incorporated the wording from
the later proposal.
Y SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
Y STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
Y STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
Y STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
We vote Yes for all three proposals on this issue, but really prefer
the first one, namely STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS.
N STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
We "buy" Gail Zacharias' arguments about a false illusion of portability.
Y SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
Y SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
Y SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
Y TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
N TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
It's a waste of time to worry about TAILP; it's not worth bothering about.
N TEST-NOT-IF-NOT:FLUSH-ALL
N TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
Y TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
Y UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
Y VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
∂12-Jan-89 0924 CL-Cleanup-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89 09:24:48 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 520199; Thu 12-Jan-89 12:22:52 EST
Date: Thu, 12 Jan 89 12:22 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890112-003154-11895@Xerox>
Message-ID: <890112122239.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 12 Jan 89 00:30 PST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
[lmm: from Ballot]
I can understand why someone might find the need for :UNSPECIFIC
in Unix unclear, but I think that is because it is not clear what
filenames would be parsed as pathnames with :UNSPECIFIC type [*];
:UNSPECIFIC is nonetheless useful for building pathnames directly
when you know which case you want and need a way to specify it.
[*] Does a name without "." parse as type NIL or :UNSPECIFIC?
Different Unix programs use different conventions. Some are
willing to merge in a type field, others, such as the C compiler,
leave names as-is. So the "right" answer may vary.
Symbolics systems have a consistent rule for use in the absence of a file
system specific convention: assume that the last dot (if any) separates the
name from the type.
If there is no last dot, then the type is :UNSPECIFIC. If there is a last
dot, then the text to the right (even if null) is the type and the text to
the left (even if null) is the name.
This rule means that:
"." has name "" and type "".
".." has name "." and type "".
You might say that this is not the optimal mapping, but after all:
"." and ".." were quite obviously chosen to be screwy file names so
they wouldn't get in the way of other more important namespaces.
If you look at it that way, it's quite appropriate that they get
internal names which are not "easy" to generate.
Whether "." was name "." and type :unspecific (as I mentioned
is possible) or name "" and type "" (as we implement), it would not
merge a type. In either case, you could make a new pathname with
the same fields but with :TYPE NIL and then it would merge a type.
Anyway, just to flesh this out,
"Foo" has name "Foo" and type :UNSPECIFIC.
"Foo." has name "Foo" and type ""
"Foo.Bar.Lisp" has name "Foo.Bar" and type "Lisp"
".Lisp" has name "" and type "Lisp"
I wasn't involved in the choice of how this was partitioned and I admit
to being surprised at the partitioning, but I've come to believe that it
was the correct thing. For example, it would be very much the wrong thing
if a double-dot made for a dotted extension (ie, "Foo.Bar.Lisp" had name
"Foo" and type "Bar.Lisp") so you have to take the dots from the right.
It would not cause internal confusion to exempt "." and ".." and say
that they parsed as name "." and type :unspecific,etc. since in fact
there is no namestring which will parse to that. On the other hand, while
it might appease some people, it would make the rule harder to remember.
Anyway, I'm not so much proposing that we standardize this kind of thing
because personally I think it's very inappropriate for a generic
standard like the one we're making to favor some vendors over others
(since it's clear that we can't have info on everyone). I was just trying
to give you a flavor of where I'm coming from in all this.
By the way -- someone asked about why "Foo" can't be parsed as
name "Foo" and type NIL. The answer is that it doesn't merge correctly.
If your file defaults are something with an extension (eg, name "Foo"
and type "Lisp"), and you do (OPEN "Baz"), you should to open "Baz",
not "Baz.Lisp". If you don't, there is no way to open "Baz" without
putting NIL in the standard pathname defaults before you do the open
to make sure that merge doesn't succeed in removing all NILs, and it's
my impression you're not supposed to be doing that kind of thing.
If #S(PATHNAME :NAME "Foo" :TYPE :UNSPECIFIC) keeps a type from merging
and #S(PATHNAME :NAME "Foo" :TYPE NIL) allows a type to merge, then
you have the best of both worlds.
∂12-Jan-89 0937 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 5)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 12 Jan 89 09:37:16 PST
Received: by ti.com id AA15485; Thu, 12 Jan 89 11:36:17 CST
Received: from Kelvin by tilde id AA22767; Thu, 12 Jan 89 11:18:47 CST
Message-Id: <2809617663-9049854@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 12 Jan 89 11:21:03 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: masinter.pa@Xerox.COM
Cc: Jon L White <jonl@lucid.com>, IIM%ECLA@ECLC.USC.EDU,
cl-cleanup@sail.stanford.edu
Subject: Re: Issue: EQUAL-STRUCTURE (Version 5)
In-Reply-To: Msg of 9 Jan 89 22:30 PST from masinter.pa@Xerox.COM
> What is current practice in this area? What does EQUALP do in current
> implementations on hash tables?
It turns out that the Explorer attempts to compare the contents of non-EQ hash
tables of the same size but gets an error in the process. Since no one has
reported this bug before, it appears that no one has been trying to use EQUALP
on hash tables. Might as well take the easy way out and specify that hash
tables are only compared by EQ.
∂12-Jan-89 0953 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 6)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 12 Jan 89 09:53:43 PST
Received: by ti.com id AA15540; Thu, 12 Jan 89 11:52:41 CST
Received: from Kelvin by tilde id AA23022; Thu, 12 Jan 89 11:32:26 CST
Message-Id: <2809618485-9099259@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 12 Jan 89 11:34:45 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: EQUAL-STRUCTURE (Version 6)
In-Reply-To: Msg of Wed, 11 Jan 89 14:39 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> - Moon contends that standard practice in Symbolics Lisp is
> for instances to be compared using EQ under EQUALP, not by
> descending. There may be performance issues involved here.
> Some agreement needs to be reached.
It is also true on the Explorer that Flavor instances are not descended by
EQUALP. However, I imagine that this was just an oversight in the addition of
EQUALP to the implementation, and am of the opinion that it would be better if
it did compare the components. The only problem I can think of with doing that
is handling unbound slots; perhaps it needs to be specified that two unbound
slots are EQUALP and an unbound slot is never EQUALP to a bound slot.
∂12-Jan-89 1038 CL-Cleanup-mailer Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89 10:38:12 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 520273; Thu 12-Jan-89 13:36:09 EST
Date: Thu, 12 Jan 89 13:35 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890111-222118-11592@Xerox>
Message-ID: <890112133559.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Ah, I thought I'd dropped my pointer to this message. Even though I answered
it in mail to Jeff a bit ago, I want to make sure it's filed where the answer
can be found, since it's important:
Date: 11 Jan 89 22:20 PST
From: masinter.pa@Xerox.COM
I hadn't given much thought to this issue before. In Medley, we represented
"unspecific" components by the empty string.
The null type is not what we call an unspecific component.
I.e., "foo." => (host nil device nil directory nil name "foo" type ""
version nil),
This is a null type.
while "foo" => (host nil device nil directory nil name "foo" type nil
version nil).
This is an unspecific type, but it cannot be represented this way because of
reasons outlined in the problem description of this proposal.
Why do you need a separate keyword?
It doesn't merge right. If I have two Unix files "stuff" and "stuff.l" and I do
(OPEN "stuff") from within Lisp while the file defaults are for "/joe/foo.l"
then, you will open "stuff.l" rather than "stuff" if you have represented the
unspecific type as NIL because of the way Lisp pathname merging is defined to
work.
Since Unix allows you to create files which deliberately have no type (and so
do not want to have a type merged into them), there must be a way to distinguish
"This pathname has no type but wants one." (type = NIL)
from
"This pathname has not type for a reason." (type = :UNSPECIFIC)
from
"This pathname has a type which is null." (type = "")
I hope this helps clarify things.
∂12-Jan-89 1054 CL-Cleanup-mailer Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 10:53:58 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 10:51:24 PST
Date: 12 Jan 89 10:49 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 12 Jan 89 13:35 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890112-105124-12781@Xerox>
Yes, I remember this now, sorry.
∂12-Jan-89 1106 CL-Cleanup-mailer Re: Issue: PROCLAIM-SPECIAL (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 11:05:57 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 11:02:42 PST
Date: 12 Jan 89 11:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PROCLAIM-SPECIAL (Version 9)
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
message of 12 Jan 89 00:34 PST
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890112-110242-12820@Xerox>
I made a mistake when sending out the message; the Subject is incorrect.
The issue name is PROCLAIM-LEXICAL, of course.
∂12-Jan-89 1106 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 10)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 11:05:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 10:56:13 PST
Date: 12 Jan 89 10:55 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DECLARE-TYPE-FREE (Version 10)
To: cl-cleanup@Sail.Stanford.Edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-105613-12795@Xerox>
I'm not distributing this to X3J13 just in case there are *more*
edits necessary.
!
Forum: Cleanup
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Related issues: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
DECLARATION-SCOPE
SPECIAL-TYPE-SHADOWING
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Version 5, 30-Sep-88, Masinter (cost to implementors)
Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
Version 7, 5-Dec-88, Masinter (scope->extent)
Version 8, 7-Dec-88, Masinter (back to scope)
Version 9, 2-Jan-89, Moon (2 proposals, to clarify discussion)
Version 10, 12-Jan-89, Masinter (add back lost v.6 phrase
re nested declarations)
Problem description:
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
any effect:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
(incf y)
...random algorithm...))
Proposal (DECLARE-TYPE-FREE:ALLOW):
Specify that a type declaration does not only "affect variable bindings";
rather, type declarations are legal in all declarations. The interpretation
of a type declaration is that, during the execution of any expression
within the scope of the declaration, it is an error for the value of
the declared variable not to be of the declared type. For declarations
that are associated with variable bindings, the type declaration also
applies to the initial binding of the variable. In the special case
of a declaration for which there are no executable expressions
within the scope of the declaration (e.g., (locally (declare (integer x)))),
the result is as if there were executable expressions.
In this proposal, a type declaration affects not only variable
references within its scope, but also affects variable references that
are outside the scope of the declaration but dynamically inside the
execution of a form that is itself inside the scope of the
declaration. Such references can exist when the variable is SPECIAL
or when the declaration is not attached to the variable's binding, so
that the scope of the declaration does not include the entire scope
of the variable.
Clarify that if nested type declarations refer to the same variable,
then the value of the variable must be a member of the intersection of
the declared types.
Proposal (DECLARE-TYPE-FREE:LEXICAL):
Specify that a type declaration does not only "affect variable bindings";
rather, type declarations are legal in all declarations. The interpretation
of a type declaration is that, during the execution of any reference to the
declared variable within the scope of the declaration, it is an error for
the value of the declared variable not to be of the declared type; and
during the execution of any SETQ of the declared variable within the scope
of the declaration, it is an error for the newly assigned value of the
declared variable not to be of the declared type; and at the moment the
scope of the declaration is entered, it is an error for the value of the
declared variable not to be of the declared type.
In this proposal, a type declaration affects only variable references within
its scope, and the meaning of "free" and "variable-binding-associated" type
declarations can be described identically.
This proposal is equivalent to saying that the meaning of a type declaration
is equivalent to changing each reference to <var> within the scope of the
declaration to (THE <type> <var>), changing each expression assigned to the
variable within the scope of the declaration to (THE <type> <new-value>),
and executing (THE <type> <var>) at the moment the scope of the declaration
is entered.
Clarify that if nested type declarations refer to the same variable,
then the value of the variable must be a member of the intersection of
the declared types.
Examples:
;; this is an error under DECLARE-TYPE-FREE:ALLOW:
;; the assertion that x is a fixnum is violated between the two
;; calls to (zap)
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(zap)
x)))
;; this is an error under both proposals
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(print x)
(zap)
x)))
;; this is an error under DECLARE-TYPE-FREE:ALLOW, because
;; the assertion that x is a fixnum
;; is violated during the call to zap, even though few
;; implementations will be able to check:
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL
(let ((x 12) (y 'foo))
(flet ((zap ()
(rotatef x y)
(rotatef x y)))
(locally (declare (fixnum x))
(zap)
x)))
;; this is an error under both proposals, even though the
;; violation of the type constraint happens after the form
;; with the declaration is exited.
(let ((f (let ((x 3))
(declare (fixnum x))
#'(lambda (z) (incf x z)))))
(funcall f 4.3))
Rationale:
This proposal enables optimizing compilers to make use of the otherwise
ignored type information. Many people have often asked for it, and
there is no strong reason to forbid it.
DECLARE-TYPE-FREE:ALLOW is more restrictive on programs and hence allows
more freedom for optimizing compilers. DECLARE-TYPE-FREE:LEXICAL is easier
to understand but allows a specialized representation only where the scope
of the variable is the same as the scope of the declaration or the compiler
can prove that there are no relevant other references to the variable.
Current practice:
Lucid Common Lisp allows "free" type declarations; under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
Implementations that might currently warn about such declarations
would have to remove the warning; otherwise, it is valid to ignore
type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
every reference.
Esthetics:
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
language.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
Documentation might want to discuss the style implications of
nested declarations intersecting. The interesting cases are:
- An inner declaration could be a subtype of an outer one.
This is the most useful case and probably the only one to
be encouraged in code written by humans. e.g.,
(locally (declare (type number x))
(locally (declare (type integer x))
...use X as integer...))
- An outer declaration could be a subtype of an inner one.
This is useless but harmless. It might happen as the result
of certain macro situations. e.g.,
(locally (declare (type integer x))
(locally (declare (type number x))
...use X as integer...))
- Two types may only partially overlap. This would presumably
happen only as the result of a macro expansion.
(locally (declare (type fixnum x))
(locally (declare (type (or bit package) x))
...use X as BIT...))
∂12-Jan-89 1124 CL-Cleanup-mailer Issue: NTH-VALUE (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89 11:24:46 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 520320; Thu 12-Jan-89 14:23:03 EST
Date: Thu, 12 Jan 89 14:22 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: NTH-VALUE (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890112142253.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Some additional data on this topic, based on practical experience with
people using multiple values over the past year.
Since there is no convention for use of IGNORE or NIL in multiple-value
argument lists in Common Lisp, it is a common complaint that Cloe gets
from users of Genera that they must rewrite:
(MULTIPLE-VALUE-BIND (IGNORE Y)
(SEND FROB :READ-CURSORPOS)
...)
to do
(MULTIPLE-VALUE-BIND (IGNORE Y)
(SEND FROB :READ-CURSORPOS)
(DECLARE (IGNORE IGNORE))
...)
I usually tell them that Common Lisp is considering an NTH-VALUE
primitive so they could write
(LET ((Y (NTH-VALUE (SEND FROB :READ-CURSORPOS) 1)))
...)
and they are mostly appeased.
Recently, however, someone asked me how he could do what in
Symbolics Lisp would be written as:
(MULTIPLE-VALUE-SETQ (IGNORE Y) (SEND FROB :READ-CURSORPOS))
The only rewrites I could think of for this were much yuckier, so I
thought I'd raise the issue. With NTH-VALUE it would be
(SETQ Y (NTH-VALUE (SEND FROB :READ-CURSORPOS) 1))
but without it, all I could come up with were:
(MULTIPLE-VALUE-BIND (XX YY)
(SEND FROB :READ-CURSORPOS)
(DECLARE (IGNORE XX))
(SETQ Y YY))
or
(SETQ Y (MULTIPLE-VALUE-BIND (XX YY)
(SEND FROB :READ-CURSORPOS)
(DECLARE (IGNORE XX))
YY))
or
(SETQ Y (CADR (MULTIPLE-VALUE-LIST (SEND FROB :READ-CURSORPOS))))
I consider this case to be much yuckier than previous examples I've
seen, and it strengthens my belief in the need for NTH-VALUE.
In the absence of NTH-VALUE, we should consider the possibility
of permitting NIL in the argument list to MULTIPLE-VALUE-BIND and
MULTIPLE-VALUE-SETQ to denote an argument which is not to be assigned.
The good points of that would be
- it is fairly concise syntactically.
- it doesn't accomodate a variable index like NTH-VALUE does.
Some implementors might prefer not to have to write that code.
The bad points of that would be
- NIL can fall through from lots of places in macros, etc. so error
checking is reduced.
- it's a special case, and so aesthetically ugly to some.
- it doesn't accomodate a variable index like NTH-VALUE does.
Some users might prefer not to have to write that code.
∂12-Jan-89 1143 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 11:43:23 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 11:36:09 PST
Date: 12 Jan 89 11:34 PST
From: masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 5)
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <890112-113609-12932@Xerox>
Changes from Version 4 are:
Clarify that foo:a and bar:a cannot both be slots in the same structure.
Clarify that this only affects DEFSTRUCT macro, not STRUCTURE-CLASS.
Extend Problem Description & Rationale.
!
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References: CLtL p.308 & 86-003 p.4
Category: CLARIFICATION
Edit history: Version 1 by Skona Brittain 05/13/88
Version 2, Masinter, 14-Sep-88
Version 3, Masinter, 23-Sep-88
Version 4, Masinter, 31-Oct-88
Version 5, Masinter, 12-Jan-89
Problem Description:
The case of two slots of a structure having the same name is not
discussed in CLtL. Is it allowed? The problem is that the
name of slot accessors and the keyword arguments of the
constructor function is determined only by the SYMBOL-NAME
of the slot designator; the meaning of slot accessors and
the constructor function is unspecified.
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):
It is an error for two slots in a structure type to have the same symbol-name;
that is, the SYMBOL-NAME of the slot names should not be STRING=.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.
The situation of expanding a DEFSTRUCT macro with a duplicate name "should
signal an error." (While not yet formally defined, the intent is that
the error signalling may occur when compiling a file that contains
duplicate names or when evaluating a DEFSTRUCT form with duplicate names
in an interpreter.)
This proposal only affects the operation of the DEFSTRUCT
macro, and not the STRUCTURE-CLASS or structures defined
with DEFCLASS>
Examples:
(defstruct struc slot slot) would be an error. So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).
(defstruct struct package-1:slot package-2:slot) is also an
error. Slot accessors are interned in the current *PACKAGE*
at the time of the evalution of the DEFSTRUCT.
Rationale:
Since it would be difficult to prescribe reasonable behavior for
DEFSTRUCT, it should be considered an error.
Current Practice:
In KCL, if two slots have the same name, no warning message is
given but mysterious behavior ensues. (Their default values are
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the
second one's value can be changed by setf...)
Cost to Implementors:
None.
Cost to Users:
None.
Cost of Non-Adoption:
Possible confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
This issue was first circulated to X3J13 June 1988.
This proposal does not address the issue of whether NIL is a legitimate
slot name. There seems to be no current reason why it might be prohibitied.
The compiler committee is proposing to address generally the issue
of how macro-expansion errors during compile-file might be caught and
turned into compiler warnings.
----- End Forwarded Messages -----
∂12-Jan-89 1505 CL-Cleanup-mailer Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 12 Jan 89 15:04:26 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09068; 12 Jan 89 22:56 GMT
Date: Thu, 12 Jan 89 22:59:13 GMT
Message-Id: <21697.8901122259@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: cl-cleanup@edu.stanford.sail's message of 11 Jan 89 22:30 PST
Cc: masinter.pa@xerox.com
I would prefer to have no sequence functions take arrays than to
divide the sequence functions into two classes in this way.
∂12-Jan-89 1518 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 5)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 12 Jan 89 15:17:44 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09212; 12 Jan 89 23:08 GMT
Date: Thu, 12 Jan 89 23:11:35 GMT
Message-Id: <21725.8901122311@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: TAGBODY-CONTENTS (Version 5)
To: masinter.pa@xerox.com
In-Reply-To: masinter.pa@com.xerox's message of 12 Jan 89 00:44 PST
Cc: cl-cleanup@sail.stanford.edu
> On your ballot, you said:
>
> "Contents should be valid forms (including self-evaluating) or valid tags.
> Duplicate tags should be an error (as in the proposal)."
>
> However, the EVAL-OTHER proposal passed at the last meeting makes all
> "other" objections self-evaluating.
Right, I'd forgotten that. I'd still prefer that the contents be
described as forms rather than data.
∂12-Jan-89 1524 CL-Cleanup-mailer Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 15:24:42 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 14:53:39 PST
Date: 12 Jan 89 14:36 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
In-reply-to: Pavel.pa's message of Mon, 02 Jan 89 18:20:37 PST
To: Pavel.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.Edu
Message-ID: <890112-145339-1095@Xerox>
I'm bringing hardcopy of the "latest" drafts of issues for discussion at
X3J13. If you want me to bring this one, I'll need it by tonight.
∂12-Jan-89 1536 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME , Version 4
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 12 Jan 89 15:36:32 PST
Posted-Date: Thu, 12 Jan 89 15:36:28 PST
Message-Id: <8901122336.AA23770@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
id AA23770; Thu, 12 Jan 89 15:36:31 PST
To: cl-cleanup@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME , Version 4
Cc: goldman@vaxa.isi.edu
Date: Thu, 12 Jan 89 15:36:28 PST
Sender: goldman@vaxa.isi.edu
I think this proposal is too weak in its criterion for considering
slot name "conflict" to be an error. The ONLY effects of slot name choice
over which the programmer has no control are:
1) the determination of the slot accessor function symbol
(but this is determined not solely by the print name of the symbol; the
:conc-name and value of *package* also come into play.)
2) the keyword arguments for a keyword constructor. Maybe the parameters
for a BOA constructor as well, but CLTL is mute about whether the
correspondence between the BOA constructor formal parameters and the
symbols used to designate slot names is by name equality (string=), or
by EQ, in which case the package matters. In
3) the way the default #S printer prints things.
I prefer to think of slot names as symbols, not strings. CLtL in fact
says the slot name must be a symbol. This proposal seems to move toward
saying that all that matters is the symbols symbol-name, in which case why
not allow a string as the slot name in DEFSTRUCT? I had always assumed
that, with a conc-name of NIL, the accessor for the slot would be the symbol
I used as the slot name; not a symbol in *package* with the same name. If
I am right, then the fact that two slots have the same symbol-name does not
imply any conflict in the accessor.
I think something should be considered an error only if we are unable or
unwilling to specify its effects -- not because we consider it bad style.
So, I would be happy to say that "it is an error" to hand the reader
#S<C ... :foo value ...> for a defstruct class C having multiple slots named
FOO.
I would also be happy with -- in fact I would like it -- a proposal that
said "it is an error" for defstructs of two different classes or two slots
of the same class to yield the same accessor functions (in the case of
two different classes regardless of whether one includes the other). Notice
that this can occur even if the slot names differ:
(defstruct (fab (:conc-name "FAB")) junk cd)
(defstruct (fa (:conc-name "FA")) bcd more-junk)
both of these are specified to create an accessor FABCD in *package*. Should
we just say that whichever one happens last is the definer of FABCD, or call it
a (not necessaily signalled) error?
Since another cleanup proposal has proposed allowing defstruct constructors
to have &key in their lambda lists, even two slots of the same structure
with the same name (but different pkgs) could be suitably distinguished,
since &key allows you to specify the formal parameter name and the
"keyword" used in calls differentially.
I wouldn't object to the proposal if the
criterion for conflict were simply symbol equality, rather than name equality,
although it would still leave unaddressed accidental conflicts like the one
mentioned above.
Neil
∂12-Jan-89 1745 CL-Cleanup-mailer Issue Status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 17:44:33 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 17:33:59 PST
Date: 12 Jan 89 17:33 PST
From: masinter.pa@Xerox.COM
Subject: Issue Status
To: cl-cleanup@sail.stanford.edu
Message-ID: <890112-173359-1602@Xerox>
I'm going to have to stop if I'm going to get copies made & ready for
shipping to the meeting.
We will have to decide on which issues we will present to X3J13 for voting
in which order. I propose the following, in order:
* "block vote" only those for which there is no dissent (all Y) or no
comments on released proposal.
* Separate vote on all "ballot" issues for which no comments were recieved
(even if some N votes.)
* Discussion, possibly amendments, for "old" issues for which there is no
controversy but minor changes are necessary.
* Discussion and possibly voting (if no 2-week rule) on "new" issues we
believe are not controversial.
* Discussion of issues with great controversy or some opinion that "we're
not ready to vote on this yet".
I'm thinking about proposing that we should add an Appendix to the Draft
Standard which lists the pending issues; e.g., for each issue which is not
resolved by the last hour reserved for "cleanup", we should have a simple
majority vote / no discussion about whether the issue should be "dropped."
!
Issue status:
who mailed the vote:
1 David N Gray (TI)
2 Kim A. Barrett (IIM)
3 David Bartley (TI)
4 Sandra J Loosemore (Utah)
5 David Moon (Symbolics)
6 Dan Pierson (Encore)
7 Chris Perdue (Sun)
8 Aaron Larson (Honeywell)
9 Kathy Chapman (DEC)
10 Gail Zacharias (Apple)
11 Neil Goldman (ISI)
12 Barry Margolin (TM)
13 Jeff Dalton (U Edinburgh)
14 JonL White (Lucid)
In some cases I have changed a vote from Y to "I" (conditional) if the
comments said "Only if...." In a couple of cases I changed an "Abstain" to
"Conditional" where the associated comment indicated that as the intent. I
have frequently paraphrased comments beyond recognition. The "Comments" are
more reminders to me than to you.I didn't mark which ballots were
"official". I think I missed or miscounted some votes, but I don't think it
is crucial.
ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: new/vote?
ALIST-NIL
Version 4, 1-Oct-88
Status: Withdrawn, recommend editorial
APPEND-ATOM
Synopsis: atom case of APPEND (left out of APPEND-DOTTED)
Version 1, 6-Dec-88, Released 12-Jan-89
Status: new/vote?
APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Comments: require APPLYHOOK to accept optional ignored 3rd arg?
make explicit *APPLYHOOK* value will only get two arguments
Status: New/vote?
ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Vote: 1y2y3y4y5y6y7y8y9y10y11y12y13y14y SPECIFY
Status: block vote
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Vote: 1y3y4y5y6y7y8y9y10i11y12y13y14y UNIFY-UPGRADING
Comments: 10: if remove UPGRADED-ARRAY-ELEMENT-TYPE and
UPGRADED-COMPLEX-PART-TYPE
Discussion: Must upgrading be uniform?
Status: separate vote; amendment?
BACKQUOTE-COMMA-ATSIGN-DOT
Synopsis: `(... ,@x) vs `(... . ,x). Same, or different?
Version 1, 22-Dec-88, DRAFT released
Comments: proposals INTERCHANGABLE and DIVERGENT
comments not in writeup
Status: new/vote?
CLOSED-STREAM-OPERATIONS
Version 5, 5-Dec-88, Released 5 Dec 88
Synopsis: What operations are legal on closed streams?
Vote: 1y3y4y5y6y7y8y9y10y11y12y13y14y ALLOW-INQUIRY
Comments: 10: Want to spec value for CLOSE on closed streams. Why
undefined?
Status: vote separate
α∂
CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Comments: Too many proposals
Status: new/vote?
COERCE-INCOMPLETE
Synopsis: Extend COERCE to handle default coercions? take an optional
FROM-TYPE?
Version 2, 21-Nov-88
Status: Substantial discussion, little convergence
needs new version
COMPILE-AND-LOAD-VERBOSITY
Synopsis: how much typeout when :VERBOSE given to COMPILE and LOAD
Comment: is there an issue?
Status: not submitted?
COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: new/vote?
CONSTANT-SIDE-EFFECT
Synopsis: It is an error to do destructive operations on constants in code,
defconstant.
Version: not submitted
Status: => CONSTANT-MODIFICATION (compiler committee)
CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Vote: 1n2y3n4y5y6y7y8y9y10y11y12y12y13y14y TRANSITIVE
Comments: "not worth implementation effort"
Status: block vote
DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Vote: 1n2n3n4y5n6y7i8y9n10y11y12y13y14y NO-HOISTING
Vote: 1y2n3y4n5y6i7y8i9y10n11n12n13n14y LIMITED-HOISTING
Comments: NO-HOISTING too incompatible LIMITED-HOISTING ok, but
unconvinced of need. All examples easily solved by changing
some variable names.
6,8: support LIMITED-HOISTING if NO-HOISTING fails.
Either is better than nothing.
7: NO-HOISTING if cases hoisted by 2nd alternatives are treated as
errors and LIMITED-HOISTING fails
12: LOCALLY can always be used to hoist a declaration around an
initial value form
13: NO brings LET closer to application of LAMBDA-expressions.
The "en passant" capture in LIMITED is a bit too strange.
Status: vote on LIMITED first, NO second (if LIMITED fails)
DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Vote: 1n3y4y5y6y7y8y9y10y11y12a13a14y DELETE-FTYPE-ABBREVIATION
Comments:
5: Moon mildly opposed; gratuitously incompatible. Pitman favors
benefit of making regular outweighs costs
Status: separate vote
DECLARE-TYPE-FREE
Version 8, 7-Dec-88, Released 9-Dec-88
Vote: 1a3y4y5n6n7y8y9y10n11y13n14n ALLOW
Version 9, 2-Jan-89, Released 6-Jan-89
Vote: 5y6n10y13y14y LEXICAL
Vote: 5n6y10n13n14n ALLOW
Comments: 12: Want more discussion of merits of ALLOW vs LEXICAL
LEXICAL is consistent with SYMBOL-MACROLET-DECLARE:ALLOW
Version 10, 12-Jan-89
Status: separate voting on Version 10
---
DECLARE-TYPE-USER-DEFINED
Synopsis: allow (declare ((signed-byte 8) x y z)) for all type specifiers?
Status: Not submitted
DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Vote: 1y3y4a5y6y7y8i9y10a11y12y13a14y LIKE-ENCODE
Status: block vote
DEFINITION-DELETE
Synopsis: provide a way to get rid of structures, etc.
Status: not submitted
DEFMACRO-BODY-LEXICAL-ENVIRONMENT
Synopsis: Allow DEFMACRO at non-top-level to capture environment.
Status: not submitted to cleanup; in compiler committee
DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Vote: 1y3y4y5y6y7i8y9y10y11y12y13y14y ADDITION
Comments: Spell out "at variance"; define semantics in terms of existing
package functions. Mail 6-Jan-89
7: If we allow time for more experimental usage of this before adopting it
8: believe that "should signal an error" should be "will signal an error"
Status: separate vote
DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Synopsis: defstruct accessors are proclaimed inline
Version 2, 7-Jan-89, released 10-Jan-89
Status: New/vote?
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 2, 21-Sep-88, Released 6 Oct 88
Vote: 1y2i3y4y5y6y7i8y9y10y11y12y13i14y ALLOW-KEY
Comments: 7, 13: If the proposal is fixed as suggested by Kim Barrett
Version 3, 8-Jan-88, Released 11-Jan-89
Status: new/vote on 2 vs 3?
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Vote: 1y2y3y4y5y6y7y8y9y10y11n12y13y14y YES
Status: block vote?
DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 2, 7-Jan-89
Status: ready for release??
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 4, 31-Oct-88, Released 12-Dec-88
Vote: 1y2y3y4y5y6y7y8c9y10i12y13y14y DUPLICATES-ERROR
Version 5, 12-Jan-89
Status: vote separate
DELETE-FILE-NONEXISTENT
Version 1, 5-Oct-88
Comments: should just signal different errors?
Status: awaiting new version
DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Vote: 1n2a3n4n5y6n7n8a9y10a11y12a13a14n EXPLICITLY-VAGUE
Vote: 1y2y3y4y5i6y7y8y9n10a11n12a13a14n NO
Comments: 5: "Yes" for the NO option iff EXPLICITLY-VAGUE fails.
Status: separate vote
DOTTED-MACRO-FORMS
Vote: 1y2y3y4y5y6y7y8y9y10n11y12y13y14y ALLOW
Version 3, 15-Nov-88, Released 7-Dec-88
Status: block vote
DYNAMIC-EXTENT
Version 3, 11-Jan-89
Status: DRAFT, ready for release?
ELIMINATE-FORCED-CONSING
Synopsis: Add :RECYCLE or :MODIFY keyword arguments to sequence,
list & string functions where such arguments are useful.
Version 3, 31-Aug-88
Status: Need volunteer to pursue
ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
value in consistent format across implementations. This makes
them virtually useless. I would like to constrain the values
enough so that implementors knew what to provide as return
values, and provide some examples of intended uses."
Status: need volunteer to submit
EQUAL-STRUCTURE
Version 5, 1-Oct-88, Released 8 Oct 88
Vote: 1y2i3y4a5i6y7y8y9y10a11y12y14n STATUS-QUO
Version 6, 11-Jan-89, Released 12-Jan-89
Comments: needs amendments
Status: vote separate
ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88
Status: separate vote
EXIT-EXTENT
Summary: What happens with non-local exits out of UNWIND-PROTECT cleanup
clauses?
Version 5, 12-Dec-88, Released 12-Dec-88
Vote: 1a2n3a4n5n6c7n8n9n10n11n12n13n14n MINIMAL
Vote: 1a2i3y4y5n6c7y8y9n10y11y12y13y14n MEDIUM
Comments: MEDIUM more useful in one important case
Current vague state better than muddled attempt to fix it.
Version 6, 8-Jan-89
Status: ready for release?
EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Vote: 1y2y4y5y6y7y8y9y10y11a12y13y14y P.211
Status: block vote
FILE-LENGTH-PATHNAME
Comments: Some people didn't seem to think
this was appropriate. No one seemed very interested in writing it up.
Status: not submitted
FILE-WRITE-DATE-IF-NOT-EXISTS
Synopsis: What does FILE-WRITE-DATE do if no such file?
Version: no proposal
Status: => non-existant "error signalling" committee
FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Vote: 1n2n3n4i5y6y7n8n9y10i11n12y13y14n TIGHTEN-DEFINITION
Vote: 1y2n3y4y5n6a7n8n9n10y11y12n13n14n TIGHTEN-FIXNUM-TOSS-BIGNUM
Comments: TOSS-FIXNUM-TOSS-BIGNUM
4, 10: TIGHTEN-DEFINITION if TIGHTEN-FIXNUM-TOSS-BIGNUM is voted down
I don't think either proposal really addresses the problem adequately
doesn't do much for anyone & will break some implementations.
8: BIGNUM not useful, but there are other non useful aspects; changing
requires better justification.
12: Tossing BIGNUM is a gratuitous incompatibility
13: frequently fixnum is bigger than address/can index or count.
more portable than explicit subrange
14: We feel that fixnums could be made portably useful only if they were
required to be large enough to cover both array indices and object
counts; neither proposal is strong enough about these points
Status: separate vote
FOLLOW-SYNONYM-STREAM
Status: Not Submitted; lost in STREAM-ACCESS
FORMAT-E-EXPONENT-SIGN
Vote: 1y2y3y4a5y6y7y9y10a11a12y13y14y FORCE-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: block vote
FORMAT-NEGATIVE-PARAMETERS
Synopsis: What does FORMAT do when it gets negative numbers for count?
Version: No proposal
Comment: KMP will incorporate in the list-of-signals part of the signal
proposal
Status: need volunteer
FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Vote: 1y2y3y4y5y6y7y9y10y11y12y13y14y YES
Comments: remaining questions:
- Is PRINT-OBJECT used to print things of type FLOAT in any cases
where ~$, ~E, ~F, or ~G is used?
- Can users write any methods (including :AROUND, :BEFORE, etc) for
PRINT-OBJECT on type FLOAT?
If Yes and Yes, it matters whether any of those format ops bind
*PRINT-BASE* in order to achieve the effect prescribed by CLtL of
always printing floats in base 10. If the answer to either of those
questions is "No", then it doesn't matter.
Status: separate vote (amend to No and No?)
FORMAT-ROUNDING
Synopsis: specify that ~F rounds up
Version 1, 5-Oct-88
Comments: we don't like the proposal
recommend #+IEEE-FLOATING-POINT => round-to-nearest?
Status: withdrawn?
FUNCTION-ARGUMENT-LIST
Synopsis: want way to get argument list
Status: not submitted
FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88
Status: need new version
FUNCTION-COMPOSITION
Synopsis: Add new functions for composing function values
Version 4, 12 Dec 88, Released 12 Dec 88
Vote: 1n2n3n4n5y6a7n8n9n10a11n12i13y14n NEW-FUNCTIONS
Vote: 1n2y3n4y5i6y7i8n9n10i11n12i13i14n COMPLEMENT-AND-ALWAYS
Comments: fix Barry Margolin's complaint about the degenerate case of
COMPOSE
6, 13: COMPLEMENT-AND-ALWAYS if NEW-FUNCTIONS fails
7,10: If a name better than "ALWAYS" can be found,
or if only COMPLEMENT were in the proposal
Amend ALWAYS => CONSTANTLY?
8: error in the proposal, the example for find-if specifies AND and
DISJOIN to be equivalent
12: if one of TEST-NOT-IF-NOT passes
Status: separate vote (w/amendment(s))
FUNCTION-DEFINITION
Version 2, 09-Dec-88, Released 9 Dec 88
Vote: 1y3y4y5y6y7y8a9y10a11n12y13y14n FUNCTION-SOURCE
Comments: The name FUNCTION-SOURCE sounds too much like a source-file
facility
[Lucid has such a thing]. We might accept the proposal if the name
were SOURCE-CODE; unfortunately, though this is in Lucid's documentation,
we are not really happy with that name either.
Status: vote separate
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Vote: 1y2y3y4y5y6y7y8y9y10y11y12y13y14y RESTRICTIVE
Comments: "explanation of exactly what changes could be clearer,
and I am not completely sure I understand it"
Status: block vote
FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Vote: 1y2n3y4a5y6y7y8na9n10n11n12y13y14y USE-ACTUAL-ARGUMENT-TYPE
Status: separate vote
GC-MESSAGES
Synopsis: What about unsolicited GC messages?
Version 2, 14-Nov-88
Status: editorial UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS?
GET-MACRO-CHARACTER-DISPATCHING
Synopsis: What does GET-MACRO-CHARACTER return for dispatching macros?
Status: not submitted
GET-MACRO-CHARACTER-READTABLE
Vote: 1y3y4y5y6y7y8y9y10y11y12y12y13y13y14y NIL-STANDARD
Version 2, 8 Dec 88, Released 8 Dec 88
Comments: test case says GET-DISPATCH-MACRO-CHARACTER returns EQ
functions; not required. Fix test case.
Status: separate vote (with amendment)
HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88
status: awaiting new version
HASH-TABLE-GC
Synopsis: allow hash tables with GCable keys
Status: no proposal
HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Vote: 1a3a4n5y6y7y8a9n10n11y12y13n14y ADD-WITH-WRAPPER
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
10: should be functions
13: proposal premature. Wait until need more firm
Bothered by use of macrolet; why not INLINE function?
Status: separate vote (with amendment)
HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal
HASH-TABLE-STABILITY
Vote: 1a2y3y4c5n6a7n8c9?10c11y12y13y14y KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88, Released 12 Dec 88
Comments: Is this necessary? No time to understand.
8: Is SXHASH supposed to work accross different invocations? proposal
implies
implies otherwise?
10: Would support a simpler proposal that it is an error to
destructively modify elements of equal hash tables but ok to do so for eq
hash tables.
13: important clarification even though it may
not lead to extensive changes in practice; disagree with the
suggestions that it be shortened
Status: separate vote?
HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 8 8
Vote: 1y3y4n5y6y7y8y9y10y11y12y13y14y ADD-EQUALP
Comments: "We would really like to see = hash tables, too."
SXHASH is not quite suitable for use with
EQUALP, and so I would like the key transformation function that
is used with EQUALP to made available to the user.
Status: vote separate? Requires EQUALP clarification to work.
IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: new/vote?
IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Vote: 1y2y3y4n5y6y7i8i9y10y11y12y13y14y SELECT-ONLY
Comments: 7, 8: "Yes" if DEFPACKAGE
?: If we allow time for more experimental use of DEFPACKAGE before
adopting this.
Status: block vote
IN-SYNTAX
Synopsis: like IN-PACKAGE but for readtables
Version 1, 21-Oct-88
Comments: too narrowly focused?
Status: needs new version
INPUT-STREAM-P-CLOSED
Synopsis: What do INPUT-STREAM-P and OUTPUT-STREAM-P do on closed streams?
Status: not submitted
INPUT-STREAM-P-EXAMPLE
Synopsis: (input-stream-p (make-broadcast-stream)) is NIL
Version 1, 26-Oct-88
Status: bug report, needs no clarification?
LAMBDA-FORM
Vote: 1y3y4n5y6a7n8a9y10y11n12y13y14n NEW-MACRO
Version 4, 22-Nov-88, Released 8-Dec-88
Comments: 10 New special form would be even better.
Status: separate vote
LAMBDA-LIST-DUPLICATES
Status: withdrawn
LCM-NO-ARGUMENTS
Vote: 1y3y4y5y6y7y8y9y10y11y12y13y14y [Returns] 1
Version 1, 17 Oct 88, Released 8 Dec 88
Status: block vote
LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION
Synopsis: should LEAST-POSITIVE- and MOST-POSITIVE-XXX-FLOAT
numbers include denormalized ones in those implementations
that admit them?
Status: Not yet submitted
LET-TOP-LEVEL
Synopsis: What's top level?
Status: => clcompiler
LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: New/vote?
LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Vote: 1y3y4y5i6y7n8y9y10y11y12y13y14n DISALLOW
Comments: Don't like (DEFVAR CAR ...) example
14: Like simpler "Redefining any documented
definition on a symbol in the LISP package -- such as variables,
functions, constants, properties and property-lists, etc -- is
undefined, except for the explicitly allowed cases (e.g. dynamic
binding of variables)."
Status: separate vote (with amendment?)
LIST-TYPE-SPECIFIER
Synopsis: add a type specifier (LIST NUMBER)
Version 1, 28 Jun 88
Status: withdrawn
LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled
files
Version 1, 2-Jan-89
Status: need new version?
LOAD-TIME-EVAL
Synopsis: #, semantics not in read macro
Status: => clcompiler
LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Comments: same arguments as REQUIRE-PATHNAME-DEFAULTS?
Status: not submitted
MAKE-CONCATENATED-STREAM-EXAMPLE
Synopsis: (read (make-concatenated-stream (make-string-input-stream "1")
(make-string-input-stream "2"))) => 12?
Version 1, 26-Oct-88
Status: withdrawn, no issue (bug report to one implementation)
MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Vote: 1y2n3y4n5n6y7n8y9y10n11n12n13n14y IMPLEMENTATION-DEPENDENT
Comments: Decreases portability, incompatible, special-case, has other ways
rationale incorrect, current practice incorrect
8: People writing portable code have more subtle problems to worry
about than the default :USE list anyhow
12: When using the implementation's extensions, it is better to make
this obvious by having to specify the implementation-dependent
package
Status: separate vote
MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88
Comments: extend to take other keywords? MAKE-STRING should return
simple string always? Interaction with character proposal
Status: awaiting new version
MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Vote: 1y2y3y4y5y6y7y8y9y10y11y12y14y EXPLICITLY-VAGUE
Status: block vote
NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Vote: 1a3n4n5y6y7y8an9n10y11y12n13n14n ADD
Comments: OK, but of marginal value.
The proposal should clarify the treatment of n when it is out of range.
Any non-negative integer index values should be permitted.
NIL should result if the index argument is too large.
12: Naming values using a numeric index is like using arrays
instead of DEFSTRUCT. If there were a way to specify a
value by a symbolic name I'd go for that
13: does not complete the set of operations=>not needed for completeness
Status: separate vote
OUTPUT-STREAM-P-EXAMPLE
Synopsis: Clarify (output-stream-p (make-concatenated-stream)) is NIL?
Version 1, 26-Oct-88
Status: already clear; just bug report for one implementation
PACKAGE-CLUTTER
Vote: 1y2y3y4i5y6y7y8y9y10y11y12y13y14y REDUCE
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: stronger on properties; "implimentation"
Symbols that are special forms can have macros, be FBOUNDP
I don't see any need to restrict the use of internal symbols in
the CL package as property indicators
Stronger: implementation will not use any property names
which are on user-created packages (except by inheritance.)
Allow SETF of GET, GETF, and SYMBOL-PLIST?
Other properties also should be spelled out, as per Moon.
Status: separate vote with amendments?
PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Vote: 1y3y4a5y6y7a8y9n10i11y12y13a14y NEW-FUNCTION
Comments: Minor glitches
10: Remove the description of "correctable" error to be signalled and
handled.
This sort of detailed error protocol is not specified for any other
function
and is not appropriate here
Status: separate vote with amendment
PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: extend package accessors PACKAGE-NAME etc. to take strings too.
Status: need new version
PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?
PATHNAME-COMPONENT-CASE
Synopsis: allow ALL UPPER CASE to mean "use the 'right' case
Comments: lots of heat?
Status: => "pathname" committee
PATHNAME-EXTENSIONS
Synopsis: allow a way of telling whether a pathname is a pattern, a "funny"
file
Comments: necessary in standard?
Status: => "pathname" committee
PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: need new version
PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: need new version
PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version
PATHNAME-TYPE-UNSPECIFIC
Vote: 1y3y4i5y6y7n9y10y11y12y13y14y NEW-TOKEN
Version 1 27-Jun-88, Released 7 Oct 88
Comments: may be subsumed
Status: block vote
PATHNAME-UNSPECIFIC-COMPONENT
Version 1, 29-Dec-88, Released 12-Jan-89
Synopsis: More extensions to :UNSPECIFIC
Status: new/vote?
PATHNAME-WILD
Version 2, 6-Oct-88
Synopsis: Portable way to ask about "wildcard" pathnames?
Comments: consistent with PATHNAME-COMPONENT-CASE?
Status: => "pathname" committee
PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Vote: 1y2y3y4n5y6y7y8y9y10y11y12y13y14y FIRST-READ-CHAR
Comments: "All metastreams must now support PEEK-CHAR directly..."
conflict with the rationale for issue UNREAD-CHAR-AFTER-PEEK-CHAR,
which is to legitimize implementing PEEK-CHAR as READ-CHAR/UNREAD-CHAR?
14: "proposal could be reduced from three pages to three sentences"
Status: separate vote
PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted
PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Vote: 1y3y4i5y6y7y8y9y10y11y12y13y14y USER-FUNCTIONS-WORK
Comments: This proposal would be OK if it specified that circularity only
had to be detected for objects that are contained in slots of the
structure, not random objects that are printed out by the structure
print function. Rationale: one way to handle circular printing is
to traverse the structure to detect circularities before
printing anything.
Status: separate vote, with amendment?
PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Vote: 1n3c4n5y6y7n8i9y10n11y12y13y14i LG
Comments: change "Clarify" => "Define"
- Good idea, but insufficient experience implementing&using.
- OK in principle; want discussion to ensure talking about same thing.
- No fundamental complaint, but more experience needed before standard.
- Define the status of unproclaimed free variables.
Presumably, they are an error; compilers should issue a warning.
- I don't believe in separate "dynamic" environment, don't believe it
makes sense to support rapid access to Globals on stock hardware,
and don't understand what Scheme practices don't work in Common Lisp.
- 8: If it can be implemented easily then I'm for it.
- 14: If it is clearly spelled out that it is
an error to make a dynamic binding of a proclaimed lexical variable;
we could not find such a statement in the proposal.
Status: vote separate, amendment
PROCLAIM-SCOPE
Synopsis: PROCLAIM's scope can end at "file" boundaries?
Status: => clcompiler
PROMPT-FOR
Synopsis: Add function to ask user for a value
Status: awaiting resubmission
RANGE-OF-COUNT-KEYWORD
Version 3, 9-Oct-88, Released 14-Oct-88
Vote: 1y3y4y5y6y7y9y10y11y12y13y14y NIL-OR-INTEGER
Status: block vote
RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Vote: 1y2y3y4y5y6y7y8y9y10y11y12y13y14y INTEGER-AND-INTEGER-NIL
Status: block vote
READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Status: Not submitted
READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 2, 08-Jan-89
Comment: lengthy dissent; discussion? coercion for comparitor?
Status: need new version
REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 2, 29-Oct-87, Released 8-Oct-88
Version 4, 29-Nov-88, Released 12-Jan-89
Status: Poll? Vote?
REMF-MULTIPLE
Synopsis: What does REMF do if it sees more than one INDICATOR?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: newly released
REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Vote: 1y2y3y4y5y6y7n8y9n10y11n12y13a14i ELIMINATE
Comments: Deprecate instead. Do not remove from the Lisp package.
14: Not "don't care", unable to decide what to do.
Status: separate vote
REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Vote: 1n2n3n4n5n6n7n8a9n10y11n12n13n14y NEWLY-ALLOCATED
Vote: 1y2y3y4y5y6y7y8a9n10n11y12y13y14n MAY-SHARE
Vote: 1n2n3n4n5n6n7n8a9n10n11n12n13n14n MUST-SHARE
Comments: Add a new kind of declaration?
8: All three stink. No idea what to do.
14: We "buy" Will Clinger's argument about the semantics of APPLY.
Status: separate vote
REST-LIST-EXTENT
Synopsis: allow way to declare dynamic extent &REST
Status: incorporated in issue DYNAMIC-EXTENT
RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Vote: 1y3y4y5y6y7y8y9y10y11y12y13y14y SPECIFY
Status: block vote
ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Vote: 1y2y3y4a5y6y8a9y10n11y12y13y14n NEW-VALUE
Comments: "I liked KMP's suggestion of defining additional synonyms"
I suppose we might, instead, allow anything other than T or NIL.
That has a bit of a ternary feel to it.
14: ROOM not different than other fns with optional. Want
more "general" proposal.
Status: vote separate
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Version 6, 06-Oct-88, Released 11-Jan-89
Comments: New version scales down rejected version
Status: new/vote?
SETF-FUNCTION-VS-MACRO, SETF-PLACES
SETF-FUNCTION-VS-MACRO Version 3, 4-Nov-87, Released Nov 87
Vote: 1y3y4n5n6y7i8i9y10n11y12y13n14i SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
SETF-PLACES Version 1, 11-Nov-88, Released 9-Dec-88
Vote: 1n3n4i5n6i7y8n9n10n11n12n13n14y SETF-PLACES:ADD-SETF-FUNCTIONS
Comments: premature to vote on this issue
want unified issue
7: If SETF-PLACES:ADD-SETF-FUNCTIONS fails.
other options?
8: SFVM:SF much better than before. What about
(defmacro (setf name) ?) Yes if nothing better comes along.
SP:ASF would require code to have ugly #.
12: I don't think it's possible to define a version UNDERLYING-NAME
that returns a symbol and meets all the requirements
13: Not happy with either. First seems nicer but complicates
semantics. second looks like desperate attempt to avoid first.
14: could live with either, SFVM:SF fails to address necessary
issues of cleanup for CLOS document
Status: vote separate?
SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 1, 5-Dec-88
Status: awaiting new version
SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Vote: 1a2y4y5y6y7n8y9y10y11y12y14y DELAYED-ACCESS-STORES
7: not "right" semantics? presentation needs work even if right.
Status: separate vote?
SINGLE-FLOAT-NON-PORTABLE
Synopsis: remove SINGLE-FLOAT, DOUBLE-FLOAT a la FIXNUM?
Status: Not submitted
SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: new/vote?
SPECIAL-VARIABLE-TEST
Synopsis: Add SPECIAL-VARIABLE-P?
Version 2, 31-May-88
Status: "On hold pending SYNTACTIC-ENVIRONMENT-ACCESS"
STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Vote: 2y3y4y5y6y7y8y9y10y11y12y13y14y DEFINED-CONTRACTS
Status: block vote
STANDARD-VALUE
Synopsis: user can say binding is "temporary"
Version 1, 21-Oct-88
Comments: not worth trying to standardize now?
Status: ready for release?
STEP-ENVIRONMENT
Vote: 1y2c3y4y5i6y7y8y9?10y11y12y14y CURRENT
Version 3, 20-Jun-88, Released 7 Oct 88
Comments: need clarification: compiled STEP only interprets
what would have already been interpreted if STEP wasn't there.
Status: separate vote with amendment
STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Vote: 1n3n4i5n6y7y8i9y10i11n12y14y ADD-TYPES-PREDICATES-ACCESSORS
Vote: 1n3n4?5y6n7y8y10n11y12?14i ADD-TYPES-ACCESSORS
Vote: 1y3y4?5n6n7y8a10n11n12?14i ADD-PREDICATES-ACCESSORS
Comments: Although requiring types instead of predicates forces the
implementation
of these streams as separate types, there is no obvious serious problem
which can result from that, and it leaves open the possibility of writing
methods on particular types -- if they are also classes -- are they? The
proposal should spell this out.
Having both the types and the predicates is unnecessary clutter.
Omitting the predicates makes for less overhead with no lost
functionality.
8: TYPES-ACCESSORS, then TYPES-PREDICATES-ACCESSORS, then abstain
9: two changes to proposal
13: How many type names do not have corresponding predicates?
14: Prefer TPA, Yes if fails.
Status: separate vote with amendment(s)
STREAM-CAPABILITIES
Version 1, 7/5/88
Synopsis: SAME-SOURCE-P, SAME-DESTINATION-P, etc
Status: awaiting new version, from "pathname/file" committee?
STREAM-DEFINITION-BY-USER
Synopsis: Want user-definable stream types.
Status: not submitted
STREAM-ELEMENT-TYPE-EXAMPLES
Version 1, 26-Oct-88
Synopsis: clarify STREAM-ELEMENT-TYPE may return different values?
Status: editorial? Need new proposal?
STREAM-INFO
Version 6, 30-Nov-88, Released 9 dec 88
Vote: 1y3y4y5i*6y7y8y9?10n11y12y14y ONE-DIMENSIONAL-FUNCTIONS
Comments: 5: "Yes" only if the name-changing amendment passes
writeup incorrectly states that Newline is not a standard character;
Perhaps someone has confused "standard" with "graphic".
Change: LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
8: prefer amendment. Can NIL be returned?
7: complex proposal; maybe changes in detail after experience?
10: inappropriate (examples in mail)
14: buy GZ's arguments about false illusion of portability
Status: separate vote
SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Vote: 1y2y3y5y6y7y10y11y12y14y CLARIFY
Comments: complicated; not sure
If MEMBER, AND, OR, and NOT can be handled, I'd be happier if they
were handled. This proposal is nonetheless better than the status quo.
Status: block vote
SYMBOL-MACROFLET
Version 1, 30 Sep 88
Synopsis: Add SYMBOL-MACROFLET gives lexical function expansion
Status: need new version
SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Vote: 1y3y4i5y6y7y8y9y10y11y12y13y14y ALLOW
Comments: 4: Only if SYMBOL-MACROLET-SEMANTICS passes
13: note DECLARE-TYPE-FREE:LEXICAL correlation
Status: block vote
SYMBOL-MACROLET-SEMANTICS
Vote: 1y2y3y4a5y6y7y8y9y10y11a12y13y14y SPECIAL-FORM
Version 5, 30-Nov-88, Released 9 Dec 88
Comments: 9: need more clarification
Status: block vote
SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
=> clcompiler
TAGBODY-CONTENTS
Version 5, 9-Dec-88, Released 9 Dec 88
Vote: 1y3y4y5i6y7y8y9y10i12y13i14y FORBID-EXTENSION
Comments: "The term "data element" is too vague in paragraph 2 of the
proposal.
Our "Yes" vote is contingent on correcting this.
lmm changed mind.
10: We support forbidding extensions, but oppose allowing duplicate and
unreachable tags. Instead we would prefer clarifying that () is a form
and not a valid tag.
13: Contents should be valid forms (including self-evaluating) or valid
tags. Duplicate tags should be an error (as in the proposal).
Status: separate vote (with amendment?)
TAIL-RECURSION-OPTIMIZATION
Version 2
Status: => cl-compiler?
TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Vote: 1y2y3y4y5y6y7a8y9y10y11a12y14n T
Comments: Current practice is wrong. Expand to LDIFF? Add :TEST?
The EQ -> EQL change at the last minute means this is not Genera current
practice, contrary to the current practice section.
14: not worth bothering about
Status: separate vote
TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Vote: 1n3n4y5y6a7n8na9n10y11n12n13y14n FLUSH-ALL
Vote: 1n3n4i5y6a7y8na9n10y11y12n13y14n FLUSH-TEST-NOT
Comments: Unnecessary incompatible change
4: Flushing some is better than not flushing all
5: mostly happy with either,slight preference to FLUSH-ALL.
"Yes" contingent on:
- changing "remove" to "deprecate", and coming up with a
suitable policy for deprecation which allows a comfortable
transition from current practice.
- either of the FUNCTION-COMPOSITION proposals passing.
7: Perhaps deprecate these instead. They need to remain in
the LISP package. The functionality of REMOVE-IF-NOT is needed,
perhaps use the name KEEP-IF.
9: deprecate
12: Gratuitous incompatibility
13: don't oppose "depreciation" instead of deletion.
The functionality of REMOVE-IF-NOT should be preserved under
another name. Perhaps DELETE-IF-NOT too
Status: separate vote
THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: new, no vote?
TRACE-ERROR
Synopsis: TRACE should signal errors if it doesn't understand
Version 1, 20-Jun-88
Comments: is this a cleanup?
Status: withdrawn?
TRACE-FUNCTION-ONLY
Synopsis: extend TRACE to handle other specs
Comment: we don't like it
Status: withdrawn
TRUENAME-SYNTAX-ONLY
Version 1, 12-Sep-88
Synopsis: when does TRUENAME perform checking?
Comments: other options? leave more vague? Other questions?
Status: need new version => "pathname" committee
TYPE-OF-UNDERCONSTRAINED
Vote: 1y2c3y4y5i6y7i8y9n10y11y12y13y14y ADD-CONSTRAINTS
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: some "bugs" in the proposal
5: "Our "Yes" vote is contingent on the following issues being addressed:
- RANDOM-STATE should be added to the list of built-in types.
- (subtypep (type-of x) (class-of x)) => T T for all x, seems to have
been intended but is not actually said. It should be added.
- The implementation recommendation in the discussion about returning
only portable type specifiers should be discarded.
- Shouldn't this refer to classes with proper names rather than just
ones with names?
7: If fix scope of quantifiers in (a)
Amend: for all x, for all bt
(when (built-in-type-p bt)
(when (typep x bt) (assert (subtypep (type-of x) bt)))).
Status: separate vote with amendment
TYPE-SPECIFIER-PREDICATE
Synopsis: "Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time."
Comments: considerable discussion on common lisp mailing list.
Status: Not yet submitted
UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Status: new/don't vote?
UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Vote: 1y2y3y4y5y6y7y8y9y10y11y12y13y14y DONT-ALLOW
Status: block vote
UNWIND-PROTECT-NON-LOCAL-EXIT
Status: renamed to EXIT-EXTENT
VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Vote: 1y3y4y5y6y7y8n9y10y11y13y14y SYMMETRIZE
Comments: Error checking gained by disallowing (var) more important than
symmetry.
If anything (var) should be disallowed in all forms.
Status: sepaarate vote
WRITE-NEWLINE
Synopsis: Add a :NEWLINE keyword to WRITE
Version 1, 20-Oct-80
Comments: we don't like it
Status: withdrawn?
∂12-Jan-89 2036 CL-Cleanup-mailer Issue: APPEND-FIASCO (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89 20:36:21 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 520764; Thu 12-Jan-89 23:34:36 EST
Date: Thu, 12 Jan 89 23:34 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: APPEND-FIASCO (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890112233424.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: APPEND-FIASCO
Forum: Cleanup
References: APPEND (p268), NCONC (p269), Backquote (pp349-351),
issue APPEND-DOTTED, issue APPEND-ATOM,
issue BACKQUOTE-COMMA-ATSIGN-DOT-COMMA
Category: CLARIFICATION/CHANGE
Edit history: 11-Jan-89, Version 1 by Pitman (internal review at Symbolics)
12-Jan-89, Version 2 by Pitman (merge comments)
Status: For Internal Discussion
Subsumes: issue APPEND-DOTTED (already adopted by X3J13),
issue APPEND-ATOM,
issue BACKQUOTE-COMMA-ATSIGN-DOT-COMMA
Problem Description:
Issue APPEND-DOTTED sought to clarify a vague part of the language
in a useful and interesting way (which was already current practice
in several implementations).
Unfortunately, that clarification had unanticipated consequences
which give us reason to reconsider the decision:
- (APPEND "FOO" "BAR") is one example of a degenerate
case of APPEND not treated explicitly by the APPEND-DOTTED
proposal. Issue APPEND-ATOM was raised to deal with this.
The proposal suggested that this either signal an error or
return "BAR".
- The fact that `(FOO ,@X) might not return the same as
`(FOO .,X), if X were a dotted list, is another example.
Issue BACKQUOTE-COMMA-ATSIGN-DOT-COMMA was raised to deal
with this. There was disagreement about how to resolve the
problem.
Proposal (APPEND-FIASCO:DOTTED-IS-ERROR):
Revert the approval of issue APPEND-DOTTED:REPLACE.
Since its problem described in APPEND-DOTTED is also reverted, solve the
it anew in the following different way:
1. Define that the effects of passing a dotted list to APPEND or
NCONC are undefined.
2. Define that the effects of passing a non-null atom to APPEND
or NCONC are undefined.
3. Clarify that it is an error for the form following a ",@" or a ",."
to return an atom or a dotted list.
3a. Clarify that since it is permissible for the form following a
normal "," to return an atom or dotted list, there are logically
no restrictions on the return value of the form following ".,".
As such, ".," may be useful in some cases involving atoms or
dotted lists where ",@" is undefined.
4. Clarify that although (COPY-LIST x) and (APPEND x '()) agree for
all valid arguments X, COPY-LIST is defined on some values that APPEND
isn't. As such, the two are not equivalent in intent and no relation
should be made between them.
5. Observe that the above rules have these implications:
5a. Due to 1 and 2: Valid uses of APPEND and NCONC can never return
dotted lists.
5b. Due to 3: For all valid uses of ",@" before the last element of
a list, using ".," instead will produce structurally equivalent
code.
5c. Due to 3: For all valid uses of ",." before the last element of
a list, using ".," instead will produce structurally equivalent
code [although there may be differences in the side-effect
behavior].
5d. Due to 3: For all valid uses of ",@", using ",." instead will
produce structurally equivalent code [although there may be
differences in the side-effect behavior].
Test Case:
1.1 (APPEND '(A . B) '(C)) is undefined.
It might return (A C), APPEND might signal an error, memory might
be corrupted, etc.
1.2 (APPEND '(A) '(B . C)) is undefined.
It might return (A B . C), APPEND might signal an error, memory
might be corrupted, etc.
2.1 (APPEND 'A '(B)) is undefined.
It might return (B), APPEND might signal an error, memory
might be corrupted, etc.
2.2 (APPEND '(A) 'B) is undefined.
It might return (A . B), APPEND might signal an error, memory
might be corrupted, etc.
2.3 (APPEND "A" "B") is undefined.
It might return "B", it might return "AB", APPEND might signal
an error, memory might be corrupted, etc.
3.1 `(A ,@'(B . C)) is undefined.
It might return (A B . C), the operator into which ",@" expands
might signal an error, memory might be corrupted, etc.
3.2 `(A ,@'B) is undefined.
It might return (A . B), the operator into which ",@" expands
might signal an error, memory might be corrupted, etc.
3a.1 `(A .,'(B . C)) must return (A B . C).
3a.2 `(A .,'B) must return (A . B).
Rationale:
This addresses the problems originally raised in APPEND-DOTTED.
However, unlike APPEND-DOTTED, the solution suggested is to tighten
existing definitions rather than loosening them. Such an approach is
far less likely to lead to internal inconsistencies.
Keeping people from confusing (APPEND x '()) with (COPY-LIST x) is
a good idea anyway, since we might someday want to loosen the
restrictions on what arguments APPEND copies so that it doesn't
bother to copy an argument when all subsequent arguments are ().
Current Practice:
All valid implementations are presumably compatible with this,
whether they have switched to the APPEND-DOTTED behavior or not.
[Source for the following information is the writeup for
APPEND-DOTTED (Version 5), approved by X3J13:]
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement
APPEND-DOTTED:REPLACE (at least in the interpreter). Franz's
Allegro Common Lisp also conforms to that proposal except in
the case of (NCONC (LIST) 17) => 17, where it returns NIL instead
of 17.
Kyoto Common Lisp signals an error when using APPEND or NCONC on
a dotted list.
Xerox Common Lisp signals an error on APPEND of a dotted list but
permits NCONC on a dotted list.
Cost to Implementors:
None. This change is upward compatible.
Cost to Users:
Technically none. Unless this change causes an implementation to
change, no user code would be forced to change. Any user code which
does have to change was certainly not portable to begin with.
Cost of Non-Adoption:
Some people might resist the full set of changes needed to make
APPEND-DOTTED consistent throughout the language. The aesthetic
cost of having things be inconsistent in the language are probably
higher than the pragmatic costs of portability problems having some
implementations extending APPEND and NCONC in ways that are barriers
to portability.
We already have evidence (issues BACKQUOTE-COMMA-ATSIGN-DOT-COMMA
and APPEND-ATOM) that APPEND-DOTTED had consequences which were
unforseen. One risk of going forward is that other issues like them
will arise only after using this language, too late to be corrected
by the standard.
Benefits:
Implementations which do not extend APPEND and NCONC can make useful
optimizations in high speed/low safety code based on the knowledge that
they always return proper lists.
Aesthetics:
This proposal improves linguistic aesthetics, possibly at some expense to
portability [since implementations will probably differ on how they treat
the part of the contract of APPEND and NCONC which has been made vague].
Discussion:
Pitman originally wrote and supported APPEND-DOTTED based on observations
of current practice, but now believes that the price of pursuing that
approach may have been too high.
Michael Greenwald, Kent Pitman, Glenn Burke, and David Moon read version
1 of this proposal. The level of support or opposition varied, centered
around ambivalence with no strikingly strong positions in favor or against.
In spite of lack of agreement on this particular proposal, there was general
agreement that the whole situation with APPEND was getting pretty weird
and that we should at least be willing to consider alternatives in attempt
to reach a closure on these complicated issues.
Glenn Burke was the most skeptical. He doesn't like to view NCONC as a
destructive form of APPEND. He likes to think of it as a way of achieving
(RPLACD (LAST x) y). He doesn't care if it's inconsistent with APPEND.
He's mostly just worried about existing code breaking, and about loss of
functionality. This proposal was therefore not his preference, but he
didn't absolutely condemn it either.
Moon observes that in issue REMF-DESTRUCTION-UNSPECIFIED, many people
have expressed concern that the precise side-effect of NCONC should be
more well-defined than that of other destructive operators because it
has a lot of history and a lot of code depending on it. The bottom line
here was that extending the arguments (per APPEND-DOTTED) does not risk
breaking code, while restricting the arguments (per this proposal) does.
Some (not necessarily exclusive) alternatives are:
- decide that APPEND-DOTTED was right and continue with APPEND-ATOM
and BACKQUOTE-COMMA-ATSIGN-DOT-COMMA for consistency.
- back up pre-APPEND-DOTTED days and write a proposal reaffirming
the status quo, simply making disagreements and/or boundary cases
explicit.
- write a DOTTED-SHOULD-SIGNAL variant of the above proposal,
requiring implementations to signal an error at least in the
highest safety setting [though perhaps not for the last
argument; see next option]. Such a variant would implicitly
define implementations which extend APPEND and NCONC to handle
dotted lists to be non-conforming.
- a variant which weakened the restriction on argument type so
that only the last argument to APPEND and NCONC could be dotted,
but no other argument could be. This makes practical sense since
it's highly unlikely that any implementation will want to actually
verify that particular argument. [However, doing so might lose the
useful optimizations that could be done by knowing that the
results of NCONC and APPEND are always proper lists. In the long
run such optimizations might be of considerable value. Among other
things, this change to APPEND-DOTTED seems to have begun a trend
toward using ATOM rather than ENDP to end-check lists. While it
makes the language more powerful, it may also make it slower.
On the other hand, this second order problem would be lessened if
there were a PROPER-LIST type so that you could declare the inputs
to APPEND and NCONC to be proper lists, and the type of the output
could be inferred by compilers.]
A consequence of this proposal is that the optimization
(NCONC X NIL) => X
becomes legitimate for implementations that disallow dotted lists as
arguments to NCONC.
∂12-Jan-89 2112 CL-Cleanup-mailer Issue: REMF-MULTIPLE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89 21:12:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 520784; Fri 13-Jan-89 00:10:23 EST
Date: Fri, 13 Jan 89 00:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-MULTIPLE (Version 2)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <890112-151146-1173@Xerox>
Message-ID: <19890113051016.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I'll leave X3J13 off my reply.
Symbolics' records say this issue was withdrawn because it's meaningless
(it applies only in a situation that CLtL says cannot happen). So I don't
know why you're suddenly mailing it out to X3J13. Maybe you're as tired
as I am after being inundated with hundreds of messages a day for weeks
on end.
∂12-Jan-89 2157 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89 21:57:35 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 520814; Fri 13-Jan-89 00:54:45 EST
Date: Fri, 13 Jan 89 00:54 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
To: masinter.pa@Xerox.COM
cc: jonl@lucid.com, cl-cleanup@Sail.Stanford.Edu
In-Reply-To: <890111-213644-11560@Xerox>
Message-ID: <890113005433.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 11 Jan 89 21:34 PST
From: masinter.pa@Xerox.COM
... You can implement (C:TYPEP object type) by (if (simple-small-p object)
(b:typep object type) (a:typep object type)). I.e., TYPEP need not merely
be implemented by ARRAYP + a test on ARRAY-ELEMENT-TYPE.
Larry, I started off sympathetic to your point of view. The same idea
had occurred to me. But how would you implement SUBTYPEP? The problem is
that you'd have to always specify the range just in case it mattered.
Although it precludes some interesting special-purpose representation, I
take it as a pragmatic truth, independently of what I might wish, that
we can't really make this proposal work unless implementations agree to
make the upgrading depend only on the requested type and nothing else.
∂12-Jan-89 2333 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Jan 89 23:33:05 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01779g; Thu, 12 Jan 89 23:28:55 PST
Received: by bhopal id AA04490g; Thu, 12 Jan 89 23:31:12 PST
Date: Thu, 12 Jan 89 23:31:12 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901130731.AA04490@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@Sail.Stanford.Edu
In-Reply-To: masinter.pa@Xerox.COM's message of 11 Jan 89 21:34 PST <890111-213644-11560@Xerox>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
re: Why would Lucid oppose allowing other
implementors to take a different implementation strategy? Certainly your
compiler optimizations could continue to work based on your assertions
about your own array implementation types.
Your suggestion was to permit a (gratuitous) variation on upgrading
which would make reasonable compiler optimization impossible on portable
programs. The compiler optimization can only work by assuming that
there are no variations beyond the ones it "knows" about. It is
reasonable to ask for declarations about "simpleness" and about element
type; but is is not reasonable to require declarations on size.
Anyway, I though moon already put the scotch on this whole line of inquiry
due to the type separateness of strings and bit-vectors.
-- JonL --
∂13-Jan-89 0751 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 2)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 13 Jan 89 07:51:33 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA08762; Fri, 13 Jan 89 10:50:02 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA05587; Fri, 13 Jan 89 10:49:27 EST
Message-Id: <8901131549.AA05587@mist.>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 2)
Date: Fri, 13 Jan 89 10:49:25 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
References: Array type specifiers, pp. 45-46
Related issues: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, DECLARE-TYPE-FREE
Category: CHANGE
Edit history: Version 1, 7-Oct-88, Pierson
Version 2, 13-Jan-89, Pierson (Moon and JonL comments)
Problem description:
Array type specifiers appear to be useful both for declaring the
storage format of the array and for declaring the types of legal
operations on array elements. Unfortunately, the current definition
of the meaning of array type specifiers does not require an
implementation to support the second use.
Proposal (DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE):
Within the scope of an array type declaration, all references to array
elements are assumed to satisfy the exact declared element type. It
is an error if this is ever violated. A compiler may treat the code
within the scope of the array type declaration as if each access of an
array element was surrounded by an appropriate THE form.
Examples:
(DEFVAR *ONE-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 5)))
(DEFVAR *ANOTHER-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 8)))
(DEFUN FROB (AN-ARRAY)
(DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
(SETF (AREF AN-ARRAY 1) 31) ; OK
(SETF (AREF AN-ARRAY 2) 127) ; Should signal an error
(SETF (AREF AN-ARRAY 3) (* 2 (AREF AN-ARRAY 3))) ; Run-time decision needed
(LET ((FOO 0))
(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
(SETF FOO (AREF AN-ARRAY 0)))) ; Declared to be safe
(FROB *ONE-ARRAY*) ; Legal call, should signal an error
(FROM *ANOTHER-ARRAY*) ; Is probably an undetectable error
Note that the above definition of FROB is equivalent to:
(DEFUN FROB (AN-ARRAY)
(DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 1) 31))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 2) 127))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))
(* 2 (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))))
(LET ((FOO 0))
(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
(SETF FOO (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 0)))))
Given an implementation in which fixnums are 29 bits but fixnum arrays
are upgraded to signed 32-bit arrays, the following should be compiled
with all fixnum arithmetic:
(DEFUN BUMP-COUNTERS (COUNTERS)
(DECLARE (TYPE (ARRAY FIXNUM *) BUMP-COUNTERS))
(DOTIMES (I (LENGTH COUNTERS))
(INCF (AREF COUNTERS I))))
Test Cases:
TBS
Rationale:
This mandates a useful and commonly expected behavior. It complements
proposal ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, which deals with array
type specifiers as they refer to arrays as a whole.
Current practice:
???
Cost to Implementors:
TBS
Cost to Users:
Probably none; while this is technically a change, code that declares
an array to contain one thing and depends on it containing something
else is blatantly buggy.
Cost of non-adoption:
Users will continue to expect declaration syntax to be more useful
than it really is.
Performance impact:
None.
Benefits:
Array type declarations will behave in a more useful and intuitive way.
Aesthetics:
Improved because the meaning of type declarations will coincide more
clearly with their appearance.
Discussion:
Pierson supports this proposal.
∂13-Jan-89 0858 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Jan 89 08:58:45 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 520983; Fri 13-Jan-89 11:57:08 EST
Date: Fri, 13 Jan 89 11:56 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 2)
To: Pierson@mist.encore.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890113115650.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 13 Jan 89 10:49:25 EST
From: Dan L. Pierson <pierson@mist.encore.com>
...
Problem description:
Array type specifiers appear to be useful both for declaring the
storage format of the array and for declaring the types of legal
operations on array elements. Unfortunately, the current definition
of the meaning of array type specifiers does not require an
implementation to support the second use.
It doesn't require them to support the first use, either. After all,
it's optional to support type declarations in the first place.
As such, this isn't an appropriate problem description. I'll suggest
the following wording, which I think doesn't distort your purpose,
and which gets around the issue of whether type declarations are supported:
In principle, array type specifiers could be used both for declaring
the storage format of the array and for implicitly declaring the types
of the elements held by those arrays. Unfortunately, the current
definition of the meaning of array type specifiers does not explicitly
specify that the latter use of these declarations is legitimate.
This in itself would not be enough reason to rewrite the proposal since
at this point, I don't really much care about problem descriptions or
any of that other junk, as long as the proposal part is right. However,
since below I suggest you should change the proposal part, you might as
well catch this at the same time.
Proposal (DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE):
Within the scope of an array type declaration, all references to array
elements are assumed to satisfy the exact declared element type. It
is an error if this is ever violated. A compiler may treat the code
within the scope of the array type declaration as if each access of an
array element was surrounded by an appropriate THE form.
After all the fuss on DECLARE-TYPE-FREE, it's unreasonable to expect to
get away with a vague term like "scope". You must say "dynamic scope" or
"lexical scope". From the surrounding text, it seems clear to me that you
intended "lexical scope" but you should definitely spell it out.
If you write "lexical scope", you can add to the rationale that you are
consistent with SYMBOL-MACROLET-DECLARE:ALLOW and DECLARATION-SCOPE:LEXICAL.
You can also then add me to the discussion as a supporter.
If you write "dyanamic scope", you can add to the rationale that you are
consistent with DECLARATION-SCOPE:ALLOW (and you can mention that you are
gratuitously incompatible with SYMBOL-MACROLET-DECLARE:ALLOW if you like...)
You can also then add me to the discussion as firmly opposed.
∂13-Jan-89 0935 CL-Cleanup-mailer Re: Issue: NTH-VALUE (Version 4)
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 13 Jan 89 09:35:09 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac17984; 13 Jan 89 11:57 EST
Received: from draper.com by RELAY.CS.NET id ab04747; 13 Jan 89 11:41 EST
Date: Fri, 13 Jan 89 09:02 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: NTH-VALUE (Version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
re: Message from KMP of 12 Jan 89, 14:22 EST
I don't recall from the proposal, but is it true that the syntax of NTH-VALUE
is (NTH-VALUE value-returning-form index), rather than
(NTH-VALUE index value-returning-form)? Why isn't it the latter, a la NTH
and NTHCDR? Not only is it more consistent with NTH and NTHCDR that way, but
it is much easier to eyeball-parse (NTH 2 (big hairy expression)) than
(NTH (big hairy expression) 2).
Btw. ZIL supports destructuring in the argument list of MULTIPLE-VALUE-BIND,
and thus handles NIL in place of an argument as a degenerate case thereof.
(It doesn't support NIL in MULTIPLE-VALUE-SETQ, though I probably could create
a MULTIPLE-VALUE-DESETQ macro a la DESETQ if I wanted to bother.)
Apropos of multiple-value issues, shouldn't there be a portable way for a
function that is about to return multiple values to be able to determine
whether or not all of those values were actually going to be used, so it
could bypass computation of extra values if they weren't going to be needed?
Refer to CLtL, p. 134:
"It may be that...for efficiency reasons it is desired not to compute the
second value." - this from a discussion of why you might want to code
(values (floor x y)), for example. Well, if FLOOR doesn't know that only
its first value is being used, how can it take advantage of this and not
compute the second value, unless it uses some underlying low-level mechanism
to find this out?
If NTH-VALUE passes, this could get interesting. FLOOR would have to be able
to tell, for example, that only its second value was going to get used, and
avoid computing the first value. This may not make a lot of sense for FLOOR,
but there may be other functions where it does.
∂13-Jan-89 0958 CL-Cleanup-mailer Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE , Version 3
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 13 Jan 89 09:58:08 PST
Posted-Date: Fri, 13 Jan 89 09:57:56 PST
Message-Id: <8901131758.AA12171@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
id AA12171; Fri, 13 Jan 89 09:58:06 PST
To: cl-cleanup@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE , Version 3
Cc: goldman@vaxa.isi.edu
Date: Fri, 13 Jan 89 09:57:56 PST
Sender: goldman@vaxa.isi.edu
The reason I do not support this proposal is twofold:
1) It does not go far enough -- in particular, it does not enable
the print function of a structure to examine the structure instance
and conditionally "hand off" to the printer for the included (more general)
class.
2) I do not see why a more specialized class should need to directly invoke
the most general (#S) printer. I notice that no one has suggested
CLOS have an alternative to NEXT-METHOD called MOST-GENERAL-METHOD. If
there is something particular about the #S syntax, I would rather simple
have an advertised CL function PRINT-#S-STYLE(structure stream depth).
I would like to see the :print-function for defstruct beefed up as follows:
(defstruct (struc (:print-function (lambda () <body>))) ...)
When a lambda expression is used as the print-function, its body may
invoke the zero-argument lexical function (or macro, I don't really care)
(NEXT-PRINTER) to invoke the next most general printer on the
same structure, stream, and depth. The #S printer is the most general --
that is, if a structure class C does not include, directly or indirectly,
any class with its own print-function, then (NEXT-PRINTER) from
C's print function will invoke the #S printer. The purpose of this protocol
is to allow a print function to inspect the particular structure and
choose to delegate printing authority to a more general printer if the
structure does not meet its criteria.
I recognize that my proposal only provides this functionality to
print-functions specified via lambda expressions, rather than
symbols. But I haven't yet encountered a situation where I
would prefer to use a symbol rather than a lambda expression, so
that doesn't bother me. Obviously the protocol permits a programmer
to write his print-function as
(lambda (x s d) (my-printer x s d #'next-printer)
or, if NEXT-PRINTER is a lexical macro rather than a lexical function,
(lambda (x s d) (my-printer x s d #'(lambda () (next-printer))))
so you can indirect all the interesting logic through a named function
anyway.
another 2cents worth,
Neil
∂13-Jan-89 1022 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89 10:22:37 PST
Received: from Semillon.ms by ArpaGateway.ms ; 13 JAN 89 10:18:01 PST
Date: 13 Jan 89 10:17 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 13 Jan 89 00:54 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, jonl@lucid.com, cl-cleanup@Sail.Stanford.Edu
Message-ID: <890113-101801-2954@Xerox>
... however, perhaps we should just not require that SUBTYPEP work for
(ARRAY <type>) instead ....
∂13-Jan-89 1022 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89 10:22:30 PST
Received: from Semillon.ms by ArpaGateway.ms ; 13 JAN 89 10:16:49 PST
Date: 13 Jan 89 10:16 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 13 Jan 89 00:54 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, jonl@lucid.com, cl-cleanup@Sail.Stanford.Edu
Message-ID: <890113-101649-2952@Xerox>
Yes, I've come to that conclusion. If you want to hack element types more
than that, you just have to hide it, e.g., remember the requested element
type even if you give it more "bits".
∂13-Jan-89 1039 CL-Cleanup-mailer Re: Issue: REMF-MULTIPLE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89 10:39:15 PST
Received: from Semillon.ms by ArpaGateway.ms ; 13 JAN 89 10:31:04 PST
Date: 13 Jan 89 10:30 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REMF-MULTIPLE (Version 2)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 13 Jan 89 00:10 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890113-103104-2989@Xerox>
I've already sent off the new issues to be hardcopied. Yes, I'm pretty tired ...
We'll can just not bring it up at X3J13. Sorry.
∂13-Jan-89 1039 CL-Cleanup-mailer Re: Issue: APPEND-FIASCO (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89 10:39:20 PST
Received: from Semillon.ms by ArpaGateway.ms ; 13 JAN 89 10:34:16 PST
Date: 13 Jan 89 10:33 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: APPEND-FIASCO (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 12 Jan 89 23:34 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890113-103416-3005@Xerox>
I don't like this. If we made a mistake on an old issue, we should just
vote to rescind the old proposal and introduce a new one.
The Discussion section can give some of the history, if you like, e.g.,
that we originally passed APPEND-DOTTED:REPLACE but then discovered that
we'd also have to fix backquote.
I'd like this as a new version of APPEND-DOTTED brought up for
reconsideration.
∂13-Jan-89 1049 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Jan 89 10:49:29 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 521091; Fri 13-Jan-89 13:47:23 EST
Date: Fri, 13 Jan 89 13:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 3)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890113134708.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Even though this is very different (more permissive) than what I'd first
written up, I have to say I really like this rewrite a lot. It's quite
clever in the way it presents things in order to get additional flexibility.
However, I do have a few comments I'd like to see addressed before this
gets to a vote...
* I like the concept "proper part" a lot but I don't like the name.
The term "proper" for proper lists has to do with well-formed-ness
and in this context you're suggesting an incompatible meaning which
is confusing.
I suggest instead a term like "internal", "intrinsic", "private",
"unshared", etc.
[The concept of "unshared" makes me immediately scared about the
whole quote-may-copy morass, but I don't have time to think through
right now whether that's an issue that needs further clarification
or if it's just a red herring.]
* I like the concept of "saved" but it has the problem that it isn't
easy to bring up "out of context" since "save" has a lot of connotations.
If it were possible to come up with a more unique term, I think it
would help in lunch table conversations when people start getting
screwed by things that were `unintentionally saved' and others can't
figure out what they mean out of context.
* I think your list of definitions for saved is pretty good, but I'd
still like to see an abstract definition, and then the concrete cases
listed beneath it. That way, we are protected from weird unintentional
interpretations if someone discovers that the set was not exhaustive
and needs to include their new case under the abstract description
because the concrete list doesn't accomodate things.
* What about things like:
(DEFUN FOO (&REST X)
(DECLARE (DYNAMIC-EXTENT X))
(MAPL #'PRINT X)
T)
Genera's Dynamic Windows (DW) had bugs in its first release because the
window history recorded the object which was printed. Put another
way, PRINT did unexpected "saving" on some streams. The situation with
DW was treated as a bug and now DW correctly detects stack-allocated
things and does not try to save them, so this would work now.
However, it still raises the question of whether we should define
per-function for every CL function whether any of the arguments is
permitted to be "saved" so that CL programs don't get any funny surprises.
If we don't, it ends up being implementor's discretion how to resolve
cases like this, and everyone might not agree that all cases are as
obvious as this one was.
∂13-Jan-89 1052 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Jan 89 10:51:58 PST
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 521096; Fri 13-Jan-89 13:50:20 EST
Date: Fri, 13 Jan 89 13:50 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 3)
To: CL-Cleanup@Sail.Stanford.EDU
cc: DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
Supersedes: <19890106223654.4.CASSELS@GROUSE.SCRC.Symbolics.COM>,
<19890108162936.5.CASSELS@GROUSE.SCRC.Symbolics.COM>
Message-ID: <19890113185020.8.CASSELS@GROUSE.SCRC.Symbolics.COM>
Issue: REAL-NUMBER-TYPE
Forum: CLEANUP
References: Table 4-1.
Category: ADDITION
Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
and John Aspinall
08-JAN-89, Version 2 by Bob Cassels -- incorporate
Masinter's suggestion and make REAL a CLOS class
13-JAN-89, Version 3 by Cassels and Aspinall -- incorporate Marc LeBrun's
suggestions clarifying the relationship between CL
numeric type names and mathematical names
Status: For Internal Discussion
Problem Description:
There is no standard type specifier symbol for the CL type
'(OR RATIONAL FLOAT).
Proposal (REAL-NUMBER-TYPE:REAL):
Make REAL be a CL data type:
p.13 "Numbers"
Add: The NUMBER data type encompasses all of these kinds of
numbers. For convenience, there are names for some
subclasses of numbers. @i[Integers] and @i[ratios] are of
type RATIONAL. @i[Rational numbers] and @[floating-point
numbers] are of type REAL. @i[Real numbers] and @i[complex
numbers] are of type NUMBER.
Although the names of these types were chosen with the
terminology of mathematics in mind, the correspondences
are not always exact. Integers and ratios model the
corresponding mathematical concepts directly. Numbers
of the FLOAT type may be used to approximate real
numbers, both rational and irrational. The REAL type
includes all Common Lisp numbers which represent
mathematical real numbers, though there are
mathematical real numbers (irrational numbers)
which do not have an exact Common Lisp representation.
Only REAL numbers may be ordered using the <, >, <=,
and >= functions.
Compatibility note: The Fortran standard defines the term
"real datum" to mean "a processor approximation to the value
of a real number." In practice the Fortran "basic real" type
is the floating-point data type Common Lisp calls
SINGLE-FLOAT. The Fortran "double precision" type is
Common Lisp's DOUBLE-FLOAT. The Pascal "real" data type is
an "implementation-defined subset of the real numbers." In
practice this is usually a floating-point type, often what
Common Lisp calls DOUBLE-FLOAT.
A translation of an algorithm written in Fortran or Pascal
which uses "real" data usually will use some appropriate
precision of Common Lisp's FLOAT type. Some algorithms may
gain accuracy and/or flexibility by using Common Lisp's
RATIONAL or REAL types instead.
p.33 "Overlap, Inclusion, and Disjointness of Types":
Remove: The types RATIONAL, FLOAT, and COMPLEX are pairwise
disjoint subtypes of NUMBER.
Rationale: It might be thought that INTEGER and RATIO ...
Rationale: It might be thought that FIXNUM and BIGNUM ...
Add: The types RATIONAL and FLOAT are pairwise disjoint subtypes
of REAL.
The types REAL and COMPLEX are pairwise disjoint subtypes
of NUMBER.
Rationale: It might be thought that FIXNUM and BIGNUM should
form an exhaustive partition of the type INTEGER, that INTEGER
and RATIO should form an exhaustive partition of RATIONAL,
that RATIONAL and FLOAT should form an exhaustive partition of
REAL, and that REAL and COMPLEX should form an exhaustive
partition of NUMBER. These are all purposely avoided in order
to permit compatible experimentation with extensions to the
Common Lisp number system, such as the idea of adding explicit
representations of infinity or of positive and negative infinity.
p.43 Table 4-1 "Standard Type Specifier Symbols"
Add: REAL
p.49 "Type Specifiers that Abbreviate"
Add: (REAL low high)
Denotes the set of real numbers between low and high. ...
[As with RATIONAL and FLOAT.]
Make REAL a built-in CLOS class.
Proposal (REAL-NUMBER-TYPE:REALP):
Add a specific data type predicate REALP which tests for membership in
this type. [By analogy with NUMBERP.]
Test Case:
If a programmer wishes to test for "a number between 1 and 10", the
only current CL types would be '(or (rational 1 10) (float 1 10)) or
something like '(and numberp (not complexp) (satisfies range-1-10))
with (defun range-1-10 (real) (<= 1 real 10)). Both of these are
likely less efficient, and certainly less expressive than '(real 1 10).
Rationale:
Mathematics has a name for (OR RATIONAL FLOAT) -- it is "real".
This class is important because it is all the numbers which can be
ordered.
Throughout the "Numbers" chapter, the phrase "non-complex number" is
used.
MAX, MIN, p. 198 "The arguments may be any non-complex numbers."
CIS p. 207 "The argument ... may be any non-complex number."
Current Practice:
Probably nobody does this.
Cost to Implementors:
Some work is necessary to add this name. But since the underlying
type already exists the amount of work should be minimal.
Cost to Users:
Since this is an upward-compatible extension, it may be ignored by
users.
Cost of Non-Adoption:
Occasional inconvenience and/or inefficiency.
Benefits:
Mathematical clarity.
Ability to do CLOS method dispatch on the type.
Aesthetics:
As mentioned under "rationale," this would be a more concise way to
express a common programming idiom.
Discussion:
The name "non-complex number" is incorrect because future
implementations may wish to include numerical types which are neither
complex nor real. [e.g. pure imaginary numbers or quaternions]
The name "scalar" is incorrect because the mathematical concept of
scalar may indeed include complex numbers.
Fortran and Pascal use the name "real" to mean what CL calls
SINGLE-FLOAT. That should cause no significant problem, since a Lisp
program written using the type REAL will do mathematically what the
equivalent Fortran program would do. This is because Fortran's "real"
data-type is a subtype of the CL REAL type. The only differences
might be that the Lisp program could be less efficient and/or more
accurate.
A survey of several Fortran and Pascal books shows that the distinction
between INTEGER and REAL is that REAL numbers may have fractional
parts, while INTEGERs do not. Later discussions explain that REALs
cover a greater range. Much later discussions cover precision
considerations, over/underflow, etc. So the average Fortran or Pascal
programmer should be completely comfortable with the proposed Lisp
concept of REAL.
∂13-Jan-89 1053 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89 10:53:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 13 JAN 89 10:45:13 PST
Date: 13 Jan 89 10:44 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Thu, 12 Jan 89
23:31:12 PST
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, cl-cleanup@Sail.Stanford.Edu
Message-ID: <890113-104513-3046@Xerox>
I don't think we're connecting. Consider:
Implementation A has a funny upgrade strategy.
Implementation B has a regular upgrade strategy.
(My suggestion:) The standard allows implementations to have both funny and
regular upgrade strategies, i.e., it does not constrain implementations.
A portable program calls MAKE-ARRAY with some ELEMENT-TYPE arguments, and
uses those *same* element-types in declarations and programs.
Implementation B, which only allows regular upgrade strategy, can use
reasonable compiler optimizations; it can assume "there are no variations
beyond the ones it 'knows' about."
Implementation A, which employs a funny upgrade strategy, cannot use those
same compiler optimizations. Maybe it has compiler optimizations of its
own. Maybe it has special AREEF hardware.
In any case, the fact that the standard ALLOWS implementation A to have a
funny upgrade strategy does not make it impossible for implementation B to
use reasonable compiler optimizations.
Does it?
The line of inquiry is not moot due to the type separateness of strings and
bit-vectors; all it says is that upgrade strategies have to do it in such a
way as to not cross those lines.
Also, the character committee's proposal includes making some modifications
to STRING such that STRING means any vector whose element type is SUBTYPEP
to CHARACTER, and allowing more specialized strings. I think that the
interaction of that proposal and this issue should be examined carefully.
∂13-Jan-89 1109 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 3)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 13 Jan 89 11:08:43 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA12396; Fri, 13 Jan 89 14:07:06 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA05883; Fri, 13 Jan 89 14:06:32 EST
Message-Id: <8901131906.AA05883@mist.>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 3)
In-Reply-To: Your message of Fri, 13 Jan 89 11:56:00 -0500.
<890113115650.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 13 Jan 89 14:06:30 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Thanks for the comments Kent. I agree. Here is the new version.
Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
References: Array type specifiers, pp. 45-46
Related issues: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, DECLARE-TYPE-FREE,
SYMBOL-MACROLET-DECLARE
Category: CHANGE
Edit history: Version 1, 7-Oct-88, Pierson
Version 2, 13-Jan-89, Pierson (Moon and JonL comments)
Version 3, 13-Jan-89, Pierson (Pitman comments)
Problem description:
In principle, array type specifiers could be used both for declaring
the storage format of the array and for implicitly declaring the types
of the elements held by those arrays. Unfortunately, the current
definition of the meaning of array type specifiers does not explicitly
specify that the latter use of these declarations is legitimate.
Proposal (DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE):
Within the lexical scope of an array type declaration, all references
to array elements are assumed to satisfy the exact declared element
type. It is an error if this is ever violated. A compiler may treat
the code within the scope of the array type declaration as if each
access of an array element was surrounded by an appropriate THE form.
Examples:
(DEFVAR *ONE-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 5)))
(DEFVAR *ANOTHER-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 8)))
(DEFUN FROB (AN-ARRAY)
(DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
(SETF (AREF AN-ARRAY 1) 31) ; OK
(SETF (AREF AN-ARRAY 2) 127) ; Should signal an error
(SETF (AREF AN-ARRAY 3) (* 2 (AREF AN-ARRAY 3))) ; Run-time decision needed
(LET ((FOO 0))
(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
(SETF FOO (AREF AN-ARRAY 0)))) ; Declared to be safe
(FROB *ONE-ARRAY*) ; Legal call, should signal an error
(FROM *ANOTHER-ARRAY*) ; Is probably an undetectable error
Note that the above definition of FROB is equivalent to:
(DEFUN FROB (AN-ARRAY)
(DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 1) 31))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 2) 127))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))
(* 2 (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))))
(LET ((FOO 0))
(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
(SETF FOO (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 0)))))
Given an implementation in which fixnums are 29 bits but fixnum arrays
are upgraded to signed 32-bit arrays, the following should be compiled
with all fixnum arithmetic:
(DEFUN BUMP-COUNTERS (COUNTERS)
(DECLARE (TYPE (ARRAY FIXNUM *) BUMP-COUNTERS))
(DOTIMES (I (LENGTH COUNTERS))
(INCF (AREF COUNTERS I))))
Test Cases:
TBS
Rationale:
This mandates a useful and commonly expected behavior. It complements
proposal ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, which deals with array
type specifiers as they refer to arrays as a whole.
This proposal is consistent with SYMBOL-MACROLET-DECLARE:ALLOW and
DECLARATION-SCOPE:LEXICAL.
Current practice:
???
Cost to Implementors:
TBS
Cost to Users:
Probably none; while this is technically a change, code that declares
an array to contain one thing and depends on it containing something
else is blatantly buggy.
Cost of non-adoption:
Users will continue to expect declaration syntax to be more useful
than it really is.
Performance impact:
None.
Benefits:
Array type declarations will behave in a more useful and intuitive way.
Aesthetics:
Improved because the meaning of type declarations will coincide more
clearly with their appearance.
Discussion:
Pierson and Pitman support this proposal.
∂13-Jan-89 1126 CL-Cleanup-mailer Re: Issue: NTH-VALUE (Version 4)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 13 Jan 89 11:26:03 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA12473; Fri, 13 Jan 89 14:24:40 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA05936; Fri, 13 Jan 89 14:24:06 EST
Message-Id: <8901131924.AA05936@mist.>
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: NTH-VALUE (Version 4)
In-Reply-To: Your message of Fri, 13 Jan 89 09:02:00 -0500.
<8901131741.AA11635@multimax.encore.com>
Date: Fri, 13 Jan 89 14:24:04 EST
From: Dan L. Pierson <pierson@mist.encore.com>
re: Message from KMP of 12 Jan 89, 14:22 EST
I don't recall from the proposal, but is it true that the syntax
of NTH-VALUE is (NTH-VALUE value-returning-form index), rather
than (NTH-VALUE index value-returning-form)? Why isn't it the
latter, a la NTH and NTHCDR? Not only is it more consistent with
NTH and NTHCDR that way, but it is much easier to eyeball-parse
(NTH 2 (big hairy expression)) than (NTH (big hairy expression)
2).
Kent was wrong, the syntax is (NTH-VALUE index value-returning-form).
Apropos of multiple-value issues, shouldn't there be a portable
way for a function that is about to return multiple values to be
able to determine whether or not all of those values were actually
going to be used, so it could bypass computation of extra values
if they weren't going to be needed? Refer to CLtL, p. 134:
Sounds like it might be a useful feature, but it also sounds like a
new feature proposal too late in the game.
∂13-Jan-89 1129 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME , Version 4
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89 11:28:53 PST
Received: from Semillon.ms by ArpaGateway.ms ; 13 JAN 89 11:06:33 PST
Date: 13 Jan 89 11:03 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME , Version 4
In-reply-to: goldman@vaxa.isi.edu's message of Thu, 12 Jan 89 15:36:28 PST
To: goldman@vaxa.isi.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890113-110633-3112@Xerox>
If you have two slots with the same name in different packages, then the
slot accessor name for the slots will be the same; while the :conc-name and
the value of *package* come into play, the symbol-name of the slots is the
only part that is used to distinguish one slot from another.
If you had duplicate names, which slot would the accessor refer to? E.g.,
(defstruct (foo (:constructor (create-foo (bar:a baz:a))))
bar:a baz:a)
Then what is
(foo-a (create-foo 1 2))?
Is it 1 or 2?
We were unable and unwilling to specify its effects. Unable because there
was no good reason to choose one over the other. Unwilling because there is
now, in the language, a reasonable way of specifying unambiguously exactly
what you want, by giving a DEFCLASS in the structure-class.
∂13-Jan-89 1320 CL-Cleanup-mailer Re: Issue: NTH-VALUE (Version 4)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89 13:19:53 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA21689; Fri, 13 Jan 89 13:21:14 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA08561; Fri, 13 Jan 89 13:17:53 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA11212; Fri, 13 Jan 89 13:20:37 PST
Message-Id: <8901132120.AA11212@denali.sun.com>
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: NTH-VALUE (Version 4)
In-Reply-To: Your message of Fri, 13 Jan 89 09:02:00 -0500;
<8901131737.AA17270@Sun.COM> .
Date: Fri, 13 Jan 89 13:20:35 PST
From: peck@Sun.COM
>If NTH-VALUE passes, this could get interesting. FLOOR would have to be able
↑↑↑↑↑↑↑↑↑↑↑↑↑
>to tell, for example, that only its second value was going to get used, and
>avoid computing the first value. This may not make a lot of sense for FLOOR,
>but there may be other functions where it does.
Nah, it would never be *required*. p134 is talking about a "standard idiom"
for how a programmer could express the desire. A really smart compiler
that is working on an inline function that it knows a LOT about
*maybe* would make such an optimzation.
You make a good point reminding us that (VALUES (...))
is a special case of NTH-VALUE, ie (NTH-VALUE 0 (...))
Are we going to see an extension for MULTIPLE NTH-VALUES?
(multiple-value-bind (a c e)
(NTH-VALUE '(0 2 4) (...))
...)
Equivalent to the request for NIL binding:
(multiple-value-bind (a nil c nil e) (...)
...)
Yes, of course i just kidding... :)
∂13-Jan-89 1448 CL-Cleanup-mailer Ballot
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 14:48:14 PST
Date: 13 Jan 1989 17:46-EST
Sender: ROSENKING@A.ISI.EDU
Subject: Ballot
From: ROSENKING@A.ISI.EDU
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]13-Jan-89 17:46:38.ROSENKING>
←
** BALLOT **
Voter: Jeffrey Rosenking
Grumman Corporation (X3J13 Member)
This is the "official" position of Grumman Corp.
Vote
----
ARGUMENTS-UNDERSPECIFIED:SPECIFY Y
Version 4, 21-Sep-88, Mailed 4 Dec 88
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING A
Version 9, 31-Oct-88, Mailed 5 Dec 88
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY Y
Version 5, 5-Dec-88, Mailed 5 Dec 88
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE A
Version 1, 14-Sep-88, Mailed 6 Oct 88
DECLARATION-SCOPE:NO-HOISTING A
DECLARATION-SCOPE:LIMITED-HOISTING A
Version 4, 15-Nov-88, Mailed 9-Dec-88
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION Y
Version 4, 5-Dec-88, Mailed 5-Dec-88
DECLARE-TYPE-FREE:ALLOW A
Version 8, 7-Dec-88, Mailed 9-Dec-88
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE Y
Version 2, 30-Sep-88, Mailed 6 Oct 88
DEFPACKAGE:ADDITION I: If make-package
Version 7, 2-Nov-88, Mailed 5 Dec 88 is deprecated
or at least
documented as
an "old way"
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY Y
Version 2, 21-Sep-88, Mailed 6 Oct 88
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES Y
Version 3, 7 Dec 88, Mailed 12-Dec-88
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR Y
Version 4, 31-Oct-88, Mailed 12-Dec-88
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE N
DESCRIBE-INTERACTIVE:NO Y
Version 4, 15-Nov-88 , Mailed 7-Dec-88
DOTTED-MACRO-FORMS:ALLOW A
Version 3, 15-Nov-88, Mailed 7-Dec-88
EQUAL-STRUCTURE:STATUS-QUO Y
Version 5, 1-Oct-88, Mailed 8 Oct 88
EXIT-EXTENT:MINIMAL Y
EXIT-EXTENT:MEDIUM N
Version 5, 12-Dec-88, Mailed 12-Dec-88
EXPT-RATIO:P.211 Y
Version 3, 31-Oct-88, Mailed 7 Dec 88
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION Y
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM N
Version 4, 7-Dec-88, Mailed 12-Dec-88
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN Y
Version 2, 2 Oct 88, Mailed 6 Oct 88
FORMAT-PRETTY-PRINT:YES Y
Version 7, 15 Dec 88, Mailed 7 Dec 88
FUNCTION-COMPOSITION:NEW-FUNCTIONS N
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS N
Version 4, 12 Dec 88, Mailed 12 Dec 88
FUNCTION-DEFINITION:FUNCTION-SOURCE N
Version 2, 09-Dec-88 , Mailed 9 Dec 88
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE A
Version 3, 7-Dec-88, Mailed 12-Dec-88
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE Y
Version 5, 14-Nov-88 , Mailed 8-Dec-88
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD A
Version 2, 8 Dec 88, Mailed 8 Dec 88
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER A
Version 7, 8-Dec-88, Mailed 9-Dec-88
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS A
Version 1, 11-Nov-88 , Mailed 12 Dec 88
HASH-TABLE-TESTS:ADD-EQUALP A
Version 2, 8-Dec-88, Mailed 8 Dec 88
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY Y
Version 4, 12-Dec-88, Mailed 12-Dec-88
LAMBDA-FORM:NEW-MACRO Y
Version 4, 22-Nov-88, Mailed 8-Dec-88
LCM-NO-ARGUMENTS:1 Y
Version 1, 17 Oct 88, Mailed 8 Dec 88
LISP-SYMBOL-REDEFINITION:DISALLOW Y
Version 5, 22-Nov-88, Mailed 8 Dec 88
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT A
Version 2, 8 Oct 88, Mailed 12-Dec-88
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE A
Version 2, 09-Jun-88, Mailed 8 Oct 88
NTH-VALUE:ADD Y
Version 4, 8-Dec-88, Mailed 8 Dec 88
PACKAGE-CLUTTER:REDUCE Y
Version 6, 12-Dec-88, Mailed 12-Dec-881
PACKAGE-DELETION:NEW-FUNCTION N
Version 5, 21 nov 88, Mailed 8 Dec 88
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN Y
Version 1 27-Jun-88, Mailed 7 Oct 88
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR Y
Version 3, 8-Oct-88, Mailed 8 Oct 88
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK N
Version 3, 20 Sep 88, Mailed 8 Oct 88
PROCLAIM-LEXICAL:LG N
Version 9, 8-Dec-88, Mailed 12-Dec-88
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER Y
Version 3, 9-Oct-88, Mailed 14-Oct-88
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL Y
Version 1, 14-Sep-88, Mailed 7 Oct 88
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE Y
Version 6, 9 Dec 88, mailed 09 Dec 88
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
REST-LIST-ALLOCATION:MAY-SHARE
REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
STEP-ENVIRONMENT:CURRENT Y
Version 3, 20-Jun-88, mailed 7 Oct 88
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS Y
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS A
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
TEST-NOT-IF-NOT:FLUSH-ALL
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
∂13-Jan-89 1454 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Jan 89 14:53:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 521325; Fri 13-Jan-89 17:52:09 EST
Date: Fri, 13 Jan 89 17:52 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU
Message-ID: <19890113225201.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here is the updated version of this. Sorry it took so long.
I will bring a few copies of this with me to the meeting.
Issue: LOAD-OBJECTS
References: none
Related issues: LOAD-TIME-EVAL,
CONSTANT-COMPILABLE-TYPES,
CONSTANT-CIRCULAR-COMPILATION
Category: ADDITION
Forum: Cleanup
Edit history: Version 1, 2-Jan-89, by Moon (for discussion)
Version 2, 13-Jan-89, by Moon (draft updated from discussion)
Problem description:
Common Lisp doesn't provide any way to use an object of a user-defined
type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program
compiled with COMPILE-FILE. The problem is that LOAD has to be able
to "reconstruct" an equivalent object when the compiled-code file is
loaded, but the programmer has no way to tell LOAD how to do that.
Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM):
Define a new generic function named MAKE-LOAD-FORM, which takes one
argument and returns two values. The argument is an object that is
referenced as a constant or as a self-evaluating form in a file being
compiled by COMPILE-FILE. The objective is to enable LOAD to
construct an equivalent object.
The first value, called the "creation form," is a form that, when
evaluated at load time, should return an object that is equivalent to
the argument. The exact meaning of "equivalent" depends on the type
of object and is up to the programmer who defines a method for
MAKE-LOAD-FORM. This is the same type of equivalence discussed
in issue CONSTANT-COMPILABLE-TYPES.
The second value, called the "initialization form," is a form that,
when evaluated at load time, should perform further initialization of
the object. The value returned by the initialization form is ignored.
If the MAKE-LOAD-FORM method returns only one value, the
initialization form is NIL, which has no effect. If the object used
as the argument to MAKE-LOAD-FORM appears as a constant in the
initialization form, at load time it will be replaced by the
equivalent object constructed by the creation form; this is how the
further initialization gains access to the object.
Both the creation form and the initialization form can contain
references to objects of user-defined types (defined precisely below).
However, there must not be any circular dependencies in creation forms.
An example of a circular dependency is when the creation form for the
object X contains a reference to the object Y, and the creation form
for the object Y contains a reference to the object X. A simpler
example would be when the creation form for the object X contains
a reference to X itself. Initialization forms are not subject to
any restriction against circular dependencies, which is the entire
reason that initialization forms exist. See the example of circular
data structures below.
The creation form for an object is always evaluated before the
initialization form for that object. When either the creation form or
the initialization form references other objects of user-defined types
that have not been referenced earlier in the COMPILE-FILE, the
compiler collects all of the creation forms together and collects all
of the initialization forms together. All of the creation forms are
evaluated before any of the initialization forms. The order of
evaluation of the creation forms is unspecified except when the
ordering is forced by data dependencies. The order of evaluation of
the initialization forms is unspecified.
While these creation and initialization forms are being evaluated, the
objects are possibly in an uninitialized state, analogous to the state
of an object between the time it has been created by ALLOCATE-INSTANCE
and it has been processed fully by INITIALIZE-INSTANCE. Programmers
writing methods for MAKE-LOAD-FORM must take care in manipulating
objects not to depend on slots that have not yet been initialized.
It is unspecified whether LOAD calls EVAL on the forms or does some
other operation that has an equivalent effect. For example, the
forms might be translated into different but equivalent forms and
then evaluated, they might be compiled and the resulting functions
called by LOAD, or they might be interpreted by a special-purpose
interpreter different from EVAL. All that is required is that the
effect be equivalent to evaluating the forms.
COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
a constant or as a self-evaluating form, if the object's metaclass is
STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
subclass of BUILT-IN-CLASS), or any of a possibly-empty
implementation-defined list of other metaclasses. COMPILE-FILE will
only call MAKE-LOAD-FORM once for any given object (compared with EQ)
within a single file.
It is valid for user programs to call MAKE-LOAD-FORM in other
circumstances.
The function MAKE-LOAD-FORM-USING-SLOTS can be useful in user-written
MAKE-LOAD-FORM methods. Its first argument is the object. Its
optional second argument is a list of the names of the slots to
preserve; it defaults to all of the local slots.
MAKE-LOAD-FORM-USING-SLOTS returns forms that construct an equivalent
object using MAKE-INSTANCE and SETF of SLOT-VALUE for slots with
values, or SLOT-MAKUNBOUND for slots without values, or using other
functions of equivalent effect. MAKE-LOAD-FORM-USING-SLOTS returns
two values, thus it can deal with circular structures.
The default MAKE-LOAD-FORM method for STANDARD-OBJECT signals an
error.
The default MAKE-LOAD-FORM method for STRUCTURE-OBJECT returns forms
that construct an equivalent structure based on the structure name and
the slot values. This might be written using
MAKE-LOAD-FORM-USING-SLOTS, but that is not required.
Examples:
;; Example 1
(defclass my-class ()
((a :initarg :a :reader my-a)
(b :initarg :b :reader my-b)
(c :accessor my-c)))
(defmethod shared-initialize ((self my-class) ignore &rest ignore)
(unless (slot-boundp self 'c)
(setf (my-c self) (some-computation (my-a self) (my-b self)))))
(defmethod make-load-form ((self my-class))
`(make-instance ',(class-name (class-of self))
:a ',(my-a self) :b ',(my-b self)))
In this example, an equivalent instance of my-class is reconstructed
by using the values of two of its slots. The value of the third slot
is derived from those two values.
Another way to write the last form in the above example would have been
(defmethod make-load-form ((self my-class))
(make-load-form-using-slots self '(a b)))
;; Example 2
(defclass my-frob ()
((name :initarg :name :reader my-name)))
(defmethod make-load-form ((self my-frob))
`(find-my-frob ',(my-name self) :if-does-not-exist :create))
In this example, instances of my-frob are "interned" in some way.
An equivalent instance is reconstructed by using the value of the
name slot as a key for searching existing objects. In this case
the programmer has chosen to create a new object if no existing
object is found; alternatively she could have chosen to signal an
error in that case.
;; Example 3
(defclass tree-with-parent () ((parent :accessor tree-parent)
(children :initarg :children)))
(defmethod make-load-form ((x tree-with-parent))
(values
;; creation form
`(make-instance ',(class-of x) :children ',(slot-value x 'children))
;; initialization form
`(setf (tree-parent ',x) ',(slot-value x 'parent))))
In this example, the data structure to be dumped is circular, because
each parent has a list of its children and each child has a reference
back to its parent. Suppose make-load-form is called on one object in
such a structure. The creation form creates an equivalent object and
fills in the children slot, which forces creation of equivalent
objects for all of its children, grandchildren, etc. At this point
none of the parent slots have been filled in. The initialization form
fills in the parent slot, which forces creation of an equivalent
object for the parent if it was not already created. Thus the entire
tree is recreated at load time. At compile time, MAKE-LOAD-FORM is
called once for each object in the true. All of the creation forms
are evaluated, in unspecified order, and then all of the
initialization forms are evaluated, also in unspecified order.
Rationale:
Only the programmer who designed a class can know the correct
way to reconstruct objects of that class at load time, therefore
the reconstruction should be controlled by a generic function.
Using EVAL as the interface for telling LOAD what to do provides
full generality.
MAKE-LOAD-FORM returns two values so that circular structures can
be handled. If CONSTANT-CIRCULAR-COMPILATION is rejected,
MAKE-LOAD-FORM will only return one value, although implementations
that make an extension to support circular constants will probably
also make the extension to accept two values from MAKE-LOAD-FORM.
A default method, such as one that makes an object whose class has the
same name and whose slots have equivalent contents, is not supplied
for DEFCLASS-defined objects, because this is inappropriate for many
objects and because it is easy to write for those objects where it is
appropriate. The function MAKE-LOAD-FORM-USING-SLOTS makes it even
easier to write.
MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT, as a hook
for the programmer to control the system's actions.
Current practice:
Symbolics Flavors has something like this, but under a different name.
The name Symbolics uses is not suitable for standardization.
JonL reports that Lucid is getting more and more requests for this.
Cost to Implementors:
This seems like only a few one-line changes in the compiled-code
file writer and reader. MAKE-LOAD-FORM-USING-SLOTS is a couple
dozen lines of code, assuming the presence of the CLOS metaobject
protocol or an implementation-dependent equivalent.
Cost to Users:
None.
Cost of non-adoption:
Serious impairment of the ability to use extended-type objects. Each
implementation will probably make up its own version of this as an
extension.
Performance impact:
None.
Benefits:
See Cost of non-adoption.
Esthetics:
No significant positive or negative impact.
Discussion:
It would be possible to define an additional level of protocol that
allows multiple classes to contribute to the reconstruction of an
object, combining initialization arguments contributed by each class.
Since a user can easily define that in terms of MAKE-LOAD-FORM without
modifying the Lisp system, it is not being proposed now.
Any type that has a read syntax is likely to appear as a quoted
constant or inside a quoted constant. Pathnames are one example, user
programs often define others. Also many implementations provide a way
to create a compiled-code file full of data (rather than compiled Lisp
programs), and such data probably include extended-type objects.
Moon supports this. David Gray and John Rose made major contributions
to the discussion that produced this improved version 2 proposal.
∂13-Jan-89 1602 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Jan 89 16:02:32 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 521384; Fri 13-Jan-89 19:00:48 EST
Date: Fri, 13 Jan 89 19:00 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 2)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU,
Common-Lisp-Object-System@SAIL.STANFORD.EDU,
CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: <19890113225201.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890113190027.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
This looks mostly very good, but ...
I'd like to see a name attached to the default function for making
structure load forms, since you're requiring it to exist anyway,
and also since there might be reason to need to revert to using it
in some structure class for which the method is shadowed by a
superior class that was not `thinking ahead.'
[I call this problem the `DESCRIBE problem,' since the analagous
problem comes up there, too.]
I also think there needs to be a rationale given to making these
functions not be the default. My personal feeling is that if it's
undefined for structures, it should be undefined for instances, and vice
versa. In my mind, they serve the same conceptual purpose, and differ
only in degree of efficiency and syntax of interface. For me, they do
not differ in weird ways like whether EQUAL or EQUALP should treat them
differently, or whether MAKE-LOAD-FORM should know how to dump them.
I think the argument you give for not having a default instance-dumping
strategy applies equally to struct-dumping, so if you're going to make
them differ, you need to say what your reasoning is.
∂13-Jan-89 1631 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Jan 89 16:31:25 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 521402; Fri 13-Jan-89 19:26:40 EST
Date: Fri, 13 Jan 89 19:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EQUAL-STRUCTURE (Version 6)
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <2809618485-9099259@Kelvin>
Message-ID: <19890114002629.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 12 Jan 89 11:34:45 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> - Moon contends that standard practice in Symbolics Lisp is
> for instances to be compared using EQ under EQUALP, not by
> descending. There may be performance issues involved here.
> Some agreement needs to be reached.
It is also true on the Explorer that Flavor instances are not descended by
EQUALP. However, I imagine that this was just an oversight in the addition of
EQUALP to the implementation, and am of the opinion that it would be better if
it did compare the components. The only problem I can think of with doing that
is handling unbound slots; perhaps it needs to be specified that two unbound
slots are EQUALP and an unbound slot is never EQUALP to a bound slot.
I really feel that it is badly wrong for EQUALP to descend into
components of "standard-objects." That is an utter violation of
abstraction. Only the designer of the class knows what makes two
objects equivalent. It might depend on information represented
elsewhere than in slots. It might depend on only some of the slots.
Instances of one class might be equivalent to instances of a different
class in some cases. This is not an implementation issue, not a
performance issue, and not an oversight; it is a fundamental issue
of abstraction and semantics.
I see only three ways to cope with this:
(1) Make EQUALP a generic function, and control its behavior with
multimethods.
(2) Make EQUALP do something with standard-objects that's not always
useful and is often dangerous. That could be use EQ, descend, or
signal an error. Of the three, using EQ is best since it's compatible
with EQUAL.
(3) Eliminate EQUALP on the grounds that it is an ill-defined concept.
Instead, use application-specific equality predicates defined by the
user as needed.
Interestingly, the proposal section of the referenced proposal says
that EQUALP is changed to descend into structures, but the discussion
section says that changing EQUALP to descend into structures was
considered and rejected on the grounds that it had serious problems.
I think the discussion is right.
∂13-Jan-89 1903 CL-Editorial-mailer Code as Spec: {Issue: THE-AMBIGUITY (Version 2)}
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Jan 89 19:03:43 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03136g; Fri, 13 Jan 89 18:59:30 PST
Received: by bhopal id AA08485g; Fri, 13 Jan 89 19:01:46 PST
Date: Fri, 13 Jan 89 19:01:46 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901140301.AA08485@bhopal>
To: cl-cleanup@sail.stanford.edu, cl-editorial@sail.stanford.edu
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 11 Jan 89 23:14 PST <890111-231458-11647@Xerox>
Subject: Code as Spec: {Issue: THE-AMBIGUITY (Version 2)}
re: Proposal (THE-AMBIGUITY:FOR-DECLARATION):
Clarify that the type specifier in
(THE type exp)
may be any valid type specifier. In the case that exp returns one
value and type is not a VALUES type specifier, (THE type exp) is
equivalent to
(LET ((g exp))
(DECLARE (TYPE type g))
g)
where "g" is a gensym.
I'm not very happy with this style of specification: instead of
spelling out what "for declaration" means, a piece of code is
offered which is allegedly "equivalent". But "equivalent" under
what terms? Does this mean that for those types for which <type>
has specialized storage (and for which the compiler takes advantage
of declarations to use that specialization) then
(THE type exp)
imples that "exp" must also be in specialized storeage?
I remember a similar misleading definition -- the one that was worked
out "on the fly" at the Boston meeting for:
(COERCE '(LAMBDA (...) ...) 'FUNCTION)
It said that such a form should be like:
(EVAL '(FUNCTION (LAMBDA (...) ...)))
[or, words like that]. Presumably this was a cheap way of trying to say
"closure in the null lexical environment". I objected to this as being a
circular definition, since both forms will be implemented by some
non-portable code in each implementation, and it is precisely the
behaviour of that non-portable action that need specification. Anyway,
I mention this now because some vendors have, upon ocasion, delivered a
subseted Common Lisp without an interpreter in it; the above-mentioned
style of definition would imply that COERCE should not work in such a
subset. But in fact, COERCE can quite easily work; it is APPLY that
probably cannot work.
Code as illustrative example, of course, is fine. And while the
colloquialisms of code segments can be a shorthand for fuller
definitions, we need to be awfully careful that we don't use it in
situations where the reader will really understand it only if he
already knows what it is trying to say.
-- JonL --
∂13-Jan-89 1913 CL-Cleanup-mailer Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89 19:13:27 PST
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Fri, 13 Jan 89 22:09:40 EST
Received: by kulla.think.com; Fri, 13 Jan 89 22:10:44 EST
Date: Fri, 13 Jan 89 22:10:44 EST
From: barmar@Think.COM
Message-Id: <8901140310.AA00713@kulla.think.com>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 11 Jan 89 23:45 PST <890111-234532-11838@Xerox>
Subject: Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
For the case of INLINE functions (in implementations where they are
supported), it is permissible to consider that performing the inlining
constitutes the read, so that an FBOUNDP check need not be done at
execution time. Put another way, the effect of FMAKUNBOUND of a function
on potentially inlined references to that function is undefined.
The same should be said about DEFCONSTANT variables.
barmar
∂13-Jan-89 2000 CL-Cleanup-mailer Issue: CLOSE-CONSTRUCTED-STREAM (Version 2)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89 19:59:49 PST
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Fri, 13 Jan 89 22:56:06 EST
Received: by kulla.think.com; Fri, 13 Jan 89 22:57:10 EST
Date: Fri, 13 Jan 89 22:57:10 EST
From: barmar@Think.COM
Message-Id: <8901140357.AA00771@kulla.think.com>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 12 Jan 89 13:58 PST <890112-135856-13358@Xerox>
Subject: Issue: CLOSE-CONSTRUCTED-STREAM (Version 2)
I think ARGUMENT-STREAM-ONLY is the only reasonable proposal. I think
of CLOSE as undoing whatever created the stream. In the case of
composite streams, this means that it undoes the constructors. Since
the constructor didn't create the constituent streams, closing the
composite shouldn't affect them.
barmar
∂13-Jan-89 2058 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 2)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89 20:58:12 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA04397; Fri, 13 Jan 89 20:59:34 PST
Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA22496; Fri, 13 Jan 89 20:56:15 PST
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
id AA18401; Fri, 13 Jan 89 20:58:49 PST
Date: Fri, 13 Jan 89 20:58:49 PST
From: jrose@Sun.COM (John Rose)
Message-Id: <8901140458.AA18401@lukasiewicz.sun.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU,
CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Fri, 13 Jan 89 17:52 EST <19890113225201.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 2)
...
The creation form for an object is always evaluated before the
initialization form for that object. When either the creation form or
the initialization form references other objects of user-defined types
that have not been referenced earlier in the COMPILE-FILE, the
compiler collects all of the creation forms together and collects all
of the initialization forms together. All of the creation forms are
evaluated before any of the initialization forms. The order of
evaluation of the creation forms is unspecified except when the
ordering is forced by data dependencies. The order of evaluation of
the initialization forms is unspecified.
...
Why does the proposal restrict the evaluation initialization forms to
such a late time? Data dependencies would allow an object X's
initialization form to be executed any time after X's creation form had
finished. Is there a reason to be more strict? I can't think of one,
but if there is one, it should be stated on the rationale.
Actually, it would be better (and no more difficult, it seems to me) to
be strict in the other direction: Objects should be initialized as early
as possible, and hence at a deterministic time. This would allow nodes
in non-circular structures to be built out of fully initialized subparts,
which is clearly something an application could need.
Here's what your paragraph would look like, given that point:
The creation form for an object X is always fully evaluated before the
initialization form for that object. This evaluation includes the
evaluation of the creation form of any user-defined object Y contained
in X's creation form, and will also include the evaluation of Y's
initialization form, if X and Y are not part of a circular chain of
initialization forms. Any circular substructures of X will be fully
initialized. Initialization forms of circular structures are
evaluated in an implementation-defined order, subject to the previous
restrictions. These rules are intended to ensure that initialization
follows creation as quickly as possible, subject to data flow.
Under these rules, noncircular data structures will be treated as if
all the initialization forms will immediately follow the creation
forms this way:
(eval `(let ((obj ,<creation-form>))
,(subst 'obj <original-object> <initialization-form>)
obj))
Furthermore, circular sub-structures will not impair the timely
initialization of non-circular containing structures. Such guarantees
will give programmers a sense of security in breaking out as much
processing as possible into the initialization form.
If this point of view is not adopted, a laissez-faire position is probably
better, and I think your paragraph above could be deleted, or rewritten thus:
The creation form for an object is always fully evaluated before the
initialization form for that object. This evaluation includes the
evaluation of creation forms of any user-defined objects contained in
the creation form, and may or may not include the evaluation of
initialization forms. However, when a "top-level object" is loaded,
all creation and initialization forms of that object must be fully
evaluated before any further loading actions are taken. These rules
are intended to allow implementations a high degree of freedom in
ordering the evaluation of creation and initialization forms, subject
to the requirements of data flow.
This paragraph needs to define the the specially-treated "top-level object",
which seems to be a concept implicit in your original paragraph. But I'd
rather see my first point adopted, and be done with top-level objects.
-- John
∂14-Jan-89 0336 CL-Cleanup-mailer Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE, v3
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 89 03:36:28 PST
Date: Mon 9 Jan 89 18:54:32-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE, v3
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12461308956.25.IIM@ECLA.USC.EDU>
> Additional arguments that do not correspond to slot names but are merely
> present to supply values used in subsequent initialization computations are
> allowed.
Actually, this wasn't what I had intended when I included [svar]. I was
assuming that svar would also have to match a slot name (and that's how I
implemented it). CLtL doesn't say anything about svars at all in DEFSTRUCT
constructors. I think your proposal is probably more generally useful.
kab
-------
∂15-Jan-89 0547 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Jan 89 05:47:45 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03805g; Sun, 15 Jan 89 05:43:29 PST
Received: by bhopal id AA11850g; Sun, 15 Jan 89 05:45:49 PST
Date: Sun, 15 Jan 89 05:45:49 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901151345.AA11850@bhopal>
To: masinter.pa@Xerox.COM
Cc: masinter.pa@Xerox.COM, cl-cleanup@Sail.Stanford.Edu
In-Reply-To: masinter.pa@Xerox.COM's message of 13 Jan 89 10:44 PST <890113-104513-3046@Xerox>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
re: In any case, the fact that the standard ALLOWS implementation A to have a
funny upgrade strategy does not make it impossible for implementation B to
use reasonable compiler optimizations.
As long as implementation A doesn't pay any attention to the declarations
that implementation B is concerned about, then it is moot even to
consider "funny" upgrades. If A does pay attention to the declarations,
then those that work in B will break in A.
For the life of me, I can't understand why you are pressing this issue,
since it's pointless to write something into the standard that A won't
use and B can't use. So why not leave it simply at the state where we
specify what B _can_ use, and what A doesn't care about.
-- JonL --
∂15-Jan-89 0557 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Jan 89 05:57:02 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03812g; Sun, 15 Jan 89 05:52:06 PST
Received: by bhopal id AA11871g; Sun, 15 Jan 89 05:54:25 PST
Date: Sun, 15 Jan 89 05:54:25 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901151354.AA11871@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Masinter.PA@Xerox.COM,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Fri, 13 Jan 89 13:47 EST <890113134708.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 3)
re: However, it still raises the question of whether we should define
per-function for every CL function whether any of the arguments is
permitted to be "saved" so that CL programs don't get any funny surprises.
If we don't, it ends up being implementor's discretion how to resolve
cases like this, and everyone might not agree that all cases are as
obvious as this one was.
PDP10 MacLisp had a similar problem w.r.t pdlnums. That is why
"identity" functions were so troublsome for it -- in order to
return a guaranteed safe value, it typically had to copy it's
pdlnum argument, thereby making some cases of "fast arithmetic"
code much worse than interpreted code! [Remember PRINT in MacLisp?
it returns T rather than it's argument for just this reason.]
It is necessary for an optimizing compiler to know something about
what happens to the data it passes along to "system" functions; for
example, it could assume that GET doesn't clobber the list given
to it, nor does it retain pointers to any part of it [what was the
terminology in the revised proposal? "saved"? and "proper part"?]
The issue LISP-SYMBOL-REDEFINITION might help here, in that an
implementation's compilers could depend upon it's own internal
database. But it wouldn't hurt at all to have some of these
requirements "up front" in the standard.
-- JonL --
∂15-Jan-89 0617 CL-Cleanup-mailer Issue: NTH-VALUE (Version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Jan 89 06:17:30 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03822g; Sun, 15 Jan 89 06:11:48 PST
Received: by bhopal id AA11926g; Sun, 15 Jan 89 06:14:08 PST
Date: Sun, 15 Jan 89 06:14:08 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901151414.AA11926@bhopal>
To: peck@Sun.COM
Cc: SEB1525@draper.com, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: peck@Sun.COM's message of Fri, 13 Jan 89 13:20:35 PST <8901132120.AA11212@denali.sun.com>
Subject: Issue: NTH-VALUE (Version 4)
re: . . . FLOOR would have to be able
↑↑↑↑↑↑↑↑↑↑↑↑↑
>to tell, for example, that only its second value was going to get used,
>and avoid computing the first value. This may not make a lot of sense
>for FLOOR, but there may be other functions where it does.
A really smart compiler that is working on an inline function that it
knows a LOT about *maybe* would make such an optimzation.
Lucid's 3.0 compiler "knows" a lot about FLOOR, and indeed optimizes
cases when only the first value is returned. This turnes out to be
extrememly important for floating point FLOOR's. This is moderately
easy to do in a compiler that has implemented type-propogation, since it
has to be aware of multiple-value contexts anyway. But it would be
significantly harder to optimize the case where only the second argument
is ultimately used, since there are so many more ways to obscure that fact.
The truncatation (no pun intended) of multiple values down into one is a
very common case -- specified at length in CLtL -- and is syntatically
easy to detect.
-- JonL --
∂18-Jan-89 1123 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Jan 89 11:23:06 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 523111; Wed 18-Jan-89 14:21:13 EST
Date: Wed, 18 Jan 89 14:21 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890118142113.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: CONDITION-RESTARTS
Forum: Cleanup
References: Common Lisp Condition System
Category: CHANGE
Edit history: 18-Jan-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
It was noted in the condition system document itself, and many people have
complained privately, that a major weakness of the condition system is the
inability to know whether a particular restart is associated with a
particular signalling action.
The problem being addressed shows itself in situations involving recursive
errors. The programmer wants to make sure that a restart obtained from
FIND-RESTART or COMPUTE-RESTARTS is in fact present for the purpose of
handling some particular error that he is actively focussed on, and not
for some other (outer) error which he was not actively trying to handle.
Proposal (CONDITION-RESTARTS:PERMIT-ASSOCIATION):
1. Define that it is an error for SIGNAL to be called on a condition
more than once.
2. Introduce a function COPY-CONDITION:
COPY-CONDITION condition [Function]
Returns a copy of the given condition.
3. Introduce a macro WITH-CONDITION-RESTARTS which can be used to
dynamically bind the association between a condition and a set
of restarts.
WITH-CONDITION-RESTARTS (condition-form restarts-form) &BODY forms
[Macro]
Evaluates CONDITION-FORM and RESTARTS-FORM, the results of which
should be a condition and a list of restarts, respectively. Then
evaluates the body of forms in implicit-progn style, returning the
last form. While in the dynamic context of the body, the function
COMPUTE-RESTARTS will, when given an argument that was the result
of evaluating the CONDITION-FORM, return the list of restarts that
was the result of evaluating the RESTARTS-FORM.
Only the innermost call to WITH-CONDITION-RESTARTS with a given
condition is relevant. In this way, the set of restarts associated
with a given condition can be dynamically extended or restricted.
Usually this macro is not used explicitly in code, since
SIGNAL-WITH-RESTARTS and ERROR-WITH-RESTARTS handle most of the
common cases in a way that is syntactically more concise.
4. Extend COMPUTE-RESTARTS, FIND-RESTART, ABORT, CONTINUE, USE-VALUE,
and STORE-VALUE to permit an optional condition object as an argument.
When the extra argument is not supplied, these functions behave
exactly as defined before. (Restarts are considered without
prejudice to whether they have been associated with conditions.)
When this argument is supplied, only restarts with the associated
with the given condition are considered. In all other respects, the
behavior is the same.
Passing a condition argument of NIL is treated the same as passing
no condition argument.
5. Add two new macros SIGNAL-WITH-RESTARTS and ERROR-WITH-RESTARTS:
SIGNAL-WITH-RESTARTS condition &rest restart-clauses [Macro]
This does several things:
1. It enters a context in which the indicated RESTART-CLAUSES
are available. They have the same form as the clauses in
a RESTART-CASE.
2. It evaluates CONDITION expression. [This is done after the
restarts are instantiated because the restarts are probably
still useful in the debugger if an error occurs during the
evaluation of the condition.] The result of the evaluation
must be a condition object.
3. It associates the condition which resulted from the evaluation
with the restarts established in step 1, using the equivalent
of WITH-CONDITION-RESTARTS.
4. It calls SIGNAL on the same condition.
ERROR-WITH-RESTARTS condition &rest restart-clauses [Macro]
Like SIGNAL-WITH-RESTARTS but uses ERROR rather than SIGNAL
in step 4.
6. Define that Common Lisp macros such as CHECK-TYPE, which are defined
to signal and to make restarts available, use the equivalent of
WITH-CONDITION-RESTARTS to associate the conditions they signal with
the defined restarts, so that users can make reliable tests not only
for the restarts being available, but also for them being available
for the right reasons.
Rationale:
1. The ability to recycle a condition object (including the ability to
resignal a condition) means that the same condition object might be
simultaneously active for two different purposes. In such a case,
no test (not even EQ) would suffice to determine whether a particular
restart belonged with a particular signalling action, since the
condition could not uniquely identify the signalling action. By saying
that a given condition may only be signalled once, we guarantee that
the condition can serve as a unique identifier for a signalling action.
2. Since there may now be some code which has begun to rely on the ability
to re-signal a condition, COPY-CONDITION will help to make this
transition easier. Instead of
(SIGNAL already-signalled-condition)
one can write:
(SIGNAL (COPY-CONDITION already-signalled-condition))
3. This is is the minimal level of support needed to set up an
association between restarts and conditions.
4. This provides a natural interface for retrieving and using the
information about the associations between conditions and restarts.
5. This provides a natural interface for the most common case of
wanting to signal a restart with some associated conditions.
Test Case:
(HANDLER-BIND ((ERROR #'(LAMBDA (C) (SIGNAL C)))) (SIGNAL "Test"))
was permissible, but this proposal makes it an error.
(DEFUN TEST-CONDITION-STUFF (OFFER-EXTRA-RESTART
USE-CONDITION-ARGUMENT
USE-FOUND-RESTART)
(HANDLER-BIND ((CONDITION
#'(LAMBDA (C)
(LET ((R0 (FIND-RESTART 'USE-VALUE))
(R1 (IF USE-CONDITION-ARGUMENT
(FIND-RESTART 'USE-VALUE C)
(FIND-RESTART 'USE-VALUE))))
(IF (AND R1 USE-FOUND-RESTART)
(INVOKE-RESTART R1 (EQ R0 R1))
(USE-VALUE (EQ R0 R1)))))))
(HANDLER-BIND ((CONDITION
#'(LAMBDA (C)
(USE-VALUE
(IF OFFER-EXTRA-RESTART
(WITH-RESTARTS
(SIGNAL (COPY-CONDITION C))
(USE-VALUE (X) (LIST 'EXTRA X)))
(SIGNAL (COPY-CONDITION C)))))))
(SIGNAL-WITH-RESTARTS (MAKE-CONDITION 'SIMPLE-CONDITION
:FORMAT-STRING "Test")
(USE-VALUE (X) X)))))
Previously, this was an error because it uses non-existent primitives, but
if you assume that
- COPY-CONDITION is implemented in the `obvious' way
- SIGNAL-WITH-RESTARTS just uses WITH-RESTARTS and SIGNAL
- FIND-RESTART ignores its last argument
in the obvious naive ways, it is possible to compare the old and new behavior:
Current Proposed
(TEST-CONDITION-STUFF NIL NIL NIL) => T T
(TEST-CONDITION-STUFF NIL NIL T) => T T
(TEST-CONDITION-STUFF NIL T NIL) => T T
(TEST-CONDITION-STUFF NIL T T) => T T
(TEST-CONDITION-STUFF T NIL NIL) => T (EXTRA T)
(TEST-CONDITION-STUFF T NIL T) => T (EXTRA T)
(TEST-CONDITION-STUFF T T NIL) => T (EXTRA NIL)
(TEST-CONDITION-STUFF T T T) => T NIL
Current Practice:
Presumably no implementation does this yet.
Cost to Implementors:
Several small, relatively modular changes.
Cost to Users:
Except for the change to the recyclability of restarts, this change is
upward compatible.
Probably very few if any users currently take advantage of recycling
restarts, so the cost to users of this change is very slight.
Even in the case where recycling is used, a straightforward rewrite in
terms of COPY-CONDITION is probably feasible.
Cost of Non-Adoption:
Use of restarts would not be nearly as reliable.
Benefits:
It would be possible to write code which was considerably more robust.
Aesthetics:
Some people might consider this proposal to make things slightly better
because it avoids some ambiguities. Others might consider it to make
things slightly worse because it adds additional complexity.
Discussion:
Pitman thinks a change of this sort is important.
∂20-Jan-89 1453 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Jan 89 14:53:41 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00528; Fri, 20 Jan 89 15:53:22 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA17398; Fri, 20 Jan 89 15:53:14 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901202253.AA17398@defun.utah.edu>
Date: Fri, 20 Jan 89 15:53:12 MST
Subject: issue PROCLAIM-LEXICAL
To: cl-cleanup@sail.stanford.edu
My gut feeling on this issue is that people would be willing to vote
it in, provided that we can guarantee that you would never have to
access the symbol's global value when there is a special binding of
the variable. I believe this was the purpose of the amendment that
was accepted (stating that "it is an error" to specially bind a variable
that has been proclaimed lexical), but there are still some other
possible cases.
Here is what I had written on the slide I prepared at the meeting.
Example #1:
(let ((broken (locally (declare (lexical foo))
#'(lambda () ... foo ...))))
(let ((foo 37))
(declare (special foo))
(funcall broken)))
Example #2:
(defparameter bar 'global-value)
(defun baz ()
(locally (declare (lexical bar))
bar))
(let ((bar 'dynamic-value))
(baz))
Amendment:
State that it is an error for a "free" LEXICAL declaration to
appear in contexts where there is no lexically visible binding of
that variable.
The problem is that, in both examples, a closure over the global value
of the variable is being created, and you cannot prevent that function
from being called when there are special bindings of the variable.
The rationale for the amendment is to make it impossible to create
such a closure in the first place.
I am not entirely convinced that there aren't other "holes" remaining
that I haven't thought about, but at least this would plug one of them.
-Sandra
-------
∂20-Jan-89 1501 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Jan 89 15:00:55 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00699; Fri, 20 Jan 89 16:00:22 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA17390; Fri, 20 Jan 89 15:35:52 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901202235.AA17390@defun.utah.edu>
Date: Fri, 20 Jan 89 15:35:50 MST
Subject: issue IN-PACKAGE-FUNCTIONALITY, version 5
To: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
Here is a new writeup on this issue, incorporating the NEW-MACRO
proposal I had written on a slide at the meeting. I have made a few
slight rearrangements and rewordings but the basic content is
unchanged.
Putting on my hat as the chair of the compiler committee, I will
repeat what I said at the meeting: if people think that this is has
become a compiler issue rather than a cleanup issue, we are willing to
take it off your hands. Let me know.
Issue: IN-PACKAGE-FUNCTIONALITY
References: IN-PACKAGE (p182-183)
Category: CHANGE
Edit history: 07-Jul-88, Version 1 by Pitman
7-Oct-88, Version 2 by Masinter (discussion)
8-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter
20-Jan-89, Version 5 by Loosemore
Related-Issues: DEFPACKAGE (passed)
CONSTANT-COMPILABLE-TYPES
Problem Description:
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
A more general problem is that the "Put In Seven Extremely Randoms"
convention described in CLtL is now recognized by many people as being
unsatisfactory for both package definition and package selection.
The DEFPACKAGE macro provides a much cleaner mechanism for package
definition, but there is still a need for a convenient way to select
a package and a concise statement of the requirements for
compile/load consistency.
Proposal (IN-PACKAGE-FUNCTIONALITY:NEW-MACRO):
Add a new macro:
WITHIN-PACKAGE name [macro]
This macro causes *PACKAGE* to be set to the package named NAME,
which must be a symbol or string. An error is signalled if the
package does not already exist. Everything this macro does is also
performed at compile time if the call appears at top-level.
Remove the function IN-PACKAGE from the standard.
Remove the second paragraph of section 11.7 in CLtL. (This includes
the requirement for special compile-time treatment of the various
package functions.) Replace it with the following language:
When a compiled file is loaded, the symbols it contains are interned
in the same package they occupied when the file was compiled. A
necessary condition for a program contained in a file to be a
conforming Common Lisp program is that, when the source file is
processed by COMPILE-FILE, all of the symbols in the file be interned
in the same package they would occupy if the source file were
loaded directly with LOAD.
Rationale:
This could allow improved error checking and modularity, with only
minimal loss of functionality.
Making WITHIN-PACKAGE a macro rather than a function means that there
is no need to require COMPILE-FILE to handle it specially.
The rationale for proposing WITHIN-PACKAGE as a replacement for
IN-PACKAGE, rather than simply changing IN-PACKAGE to have this
behavior, is that such an incompatible change would be confusing to
many people, and would make it more difficult to detect obsolete
usages. There is nothing in this proposal that would prevent
implementations from continuing to provide IN-PACKAGE as an extension.
The language in section 11.7 of CLtL puts the burden on
implementations of ensuring that all symbols in a file which is
compiled and loaded end up in the same package that they would if the
source file were loaded interpretively. No implementation can
possibly meet this requirement because, in general, the runtime
behavior of the program cannot be determined by the compiler. The
new language specifies a conformance requirement that is both
well-defined and implementable.
Current Practice:
Probably no one implements this behavior exactly since it's an
incompatible change to CLtL.
Cost to Implementors:
The WITHIN-PACKAGE macro can be implemented trivially by using
EVAL-WHEN in its expansion.
The changes required to COMPILE-FILE to support the new conformance
requirements are also likely to be small.
Cost to Users:
In most cases, minor syntactic changes to some files would be
necessary.
Cost of Non-Adoption:
The specification of COMPILE-FILE will be much more difficult to
understand.
The standard will place requirements on implementations which are
impossible to meet.
Benefits:
Modular package declarations would be encouraged and errors due
to demand-creation of packages would be easier to detect.
The specification of COMPILE-FILE will be simplified.
There will be a clear statement of the requirements for program
conformance, as relating to usage of packages.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether
the package should exist already or not) is clearly not aesthetic.
Removing it can't be any worse.
The fact that the currently stated requirements for handling of
the package functions by the compiler are not implementable is
clearly not aesthetic.
Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):
Eliminate the ability of IN-PACKAGE to create a package on demand.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
The results of calling IN-PACKAGE if the package does not already
exist are implementation dependent; implementations "should signal"
an error, or otherwise provide the user with a way to recover from
the situation.
Examples:
#1: (IN-PACKAGE 'NO-SUCH-PACKAGE) ;would signal an error
#2: (DEFPACKAGE FOO ...options...) ;defines/creates a package
(IN-PACKAGE 'FOO) ;selects an existing package
Rationale:
This could allow improved error checking and modularity, with only
minimal loss of functionality.
Current Practice:
Probably no one implements this behavior since it's in direct
contradiction of both the definitions and numerous examples in CLtL.
Cost to Implementors:
As written, no change to implementations is required, but many will
want to make IN-PACKAGE signal an error. This change would be
straightforward to implement. The cost may not be trivial in all
cases, but should not be very large.
Cost to Users:
In most cases, minor syntactic changes to some files would be
necessary.
In some cases, no changes would be necessary since files may
already be doing IN-PACKAGE in situations where the author is
hoping he's made sure the real package declaration is already
loaded.
Cost of Non-Adoption:
Reduced error checking.
Less modular code.
Benefits:
Errors due to demand-creation of a package by IN-PACKAGE without
appropriate uses of the :USE or :NICKNAMES or without appropriate
calls to EXPORT, etc. afterward would be easier to detect.
Modular package declarations would be encouraged.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether
the package should exist already or not) is clearly not aesthetic.
Some people feel this change would be an aesthetic improvement.
Others feel that an incompatible change to IN-PACKAGE would merely
be confusing.
Discussion:
The dual use of IN-PACKAGE has not been helpful and is confusing.
Both proposals represent an incompatible change to the language as
described in CLtL and will break any program that uses the "Put In
Seven Extremely Randoms" convention described in section 11.9.
Some people may find proposal NEW-MACRO more palatable if it merely
deprecated IN-PACKAGE, instead of removing it entirely.
Loosemore and Moon support proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO.
-------
∂23-Jan-89 0238 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 5
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 23 Jan 89 02:38:08 PST
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa01380; 23 Jan 89 10:13 GMT
Received: from xenakis by mordell.maths.bath.AC.UK id aa20524;
22 Jan 89 12:25 GMT
To: sandra <@cs.utah.edu:sandra@defun>
CC: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-reply-to: sandra (Sandra J Loosemore)'s message of Fri, 20 Jan 89 15:35:50 MST <8901202235.AA17390@defun.utah.edu>
Subject: issue IN-PACKAGE-FUNCTIONALITY, version 5
Date: Sun, 22 Jan 89 12:26:26 GMT
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
This is a very good idea. I have been caught by the two useds of
in-package many times too much.
==Johjn
∂23-Jan-89 0820 CL-Cleanup-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Jan 89 08:20:38 PST
Received: from fafnir.think.com by Think.COM; Mon, 23 Jan 89 10:56:42 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 23 Jan 89 11:17:02 EST
Received: by verdi.think.com; Mon, 23 Jan 89 11:15:49 EST
Date: Mon, 23 Jan 89 11:15:49 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8901231615.AA12617@verdi.think.com>
To: jonl@lucid.com
Cc: masinter.pa@xerox.com, Gray@dsg.csc.ti.com,
KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Mon, 9 Jan 89 19:54:06 PST <8901100354.AA11931@bhopal>
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Date: Mon, 9 Jan 89 19:54:06 PST
From: Jon L White <jonl@lucid.com>
re: The meta-rules for backquote were derived "after the fact" as a way to
explain what backquote did; the use of APPEND and the equivalences there
were based on the old semantics of APPEND. Now that we've extended APPEND,
we have to change the meta-rules of backquote, . . .
Your assumption here can't be true -- The MacLisp implementation (and
others) carried out the now-debased optimization; yet the meta-rules
stand. I'm very leery of changing these meta rules unless QUUX signs
off on it -- every time I've been tempted to dicker with them, I find
out that they are much deeper than a cursory glanch would suspect. [I
thought Guy devised those "meta" rules -- if he didn't then the author
ought to be consulted.]
I am responsible for the meta-rules in CLtL.
--Guy
∂23-Jan-89 1032 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jan 89 10:32:09 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 525283; Mon 23-Jan-89 13:30:02 EST
Date: Mon, 23 Jan 89 13:29 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue PROCLAIM-LEXICAL
To: CL-Cleanup@SAIL.Stanford.EDU
cc: sandra%defun@CS.UTAH.EDU
References: <8901202253.AA17398@defun.utah.edu>
Message-ID: <890123132952.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
I haven't seen an updated copy of PROCLAIM-LEXICAL. Will someone please
mail something that brings the online record up to date with the meeting?
Working from the notes Moon brought back about ammendments made:
-- Can't dynamic bind if proclaimed lexical (passed 11 to 5)
I stand firm by my claim that this is a very, very bad idea.
Programmers have been -screaming- for the ability to locally work around
the effect of having done (PROCLAIM '(SPECIAL var)) by either doing an
UNSPECIAL or LEXICAL declaration. If we're going to provide the ability to
do:
(PROCLAIM '(SPECIAL X))
(DEFUN FOO (X) (DECLARE (LEXICAL X)) (+ X 3))
(DEFUN BAR () (+ X 3))
then we should similarly provide the ability to do:
(PROCLAIM '(LEXICAL X))
(DEFUN FOO (X) (+ X 3))
(DEFUN BAR () (DECLARE (SPECIAL X)) (+ X 3))
The situations are isomorphic. They provide identical functionality. The
only question is one of notation. No power is gained by prohibiting
SPECIAL declarations of things proclaimed LEXICAL -- only frustration.
You force users to learn a complicated set of rules that buy them little
or nothing. In practice, the need to SPECIAL bind something which is
proclaimed LEXICAL probably almost never comes up, but when it does, it
should be permitted because there is no good reason not to permit it.
-- Referencing a free variable that is neither proclaimed nor declared
LEXICAL nor SPECIAL has undefined results (not voted)
This is fine.
-- A free lexical declaration of a variable with no lexically
visible binding is an error; use PROCLAIM (not voted)
This is also utter nonsense. There is no similar restriction on SPECIAL,
and it is occassionally useful. Also, there is a clear meaning. It means
you want to capture the global. Why should people assume this is a mistake.
I'm one of the people who is asking for this feature and the -reason-
I am asking for it is so I -can- capture the global. I want to be able
to capture the global. I want to be able to know that the special binding
is not in the way.
If we make a lot of doofy little special case rules about when you can
and cannot use LEXICAL and SPECIAL that are (a) unmotivated and (b)
gratuitously different for SPECIAL and LEXICAL for reasons which are
not clearly technically motivated, then we are making a big mistake that
will just complicate the language.
We cannot afford to let this issue fall off the end of the earth because
it addresses important user needs.
We cannot afford to make the language semantics overly complicated because
someone is afraid that a programmer might not mean what he wrote, even when
it has a clear meaning and a useful purpose.
Returned to committee
I hope the committee will think seriously about disregarding some of the
full committee suggestions and will spend its time instead better justifying
the position which was originally presented.
I'll probably also reply later to Sandra's message, with which I disagree
on a number of major points, but I don't have time right now.
∂23-Jan-89 1532 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 23 Jan 89 15:32:31 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08698; 23 Jan 89 23:17 GMT
Date: Mon, 23 Jan 89 23:25:50 GMT
Message-Id: <14006.8901232325@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue PROCLAIM-LEXICAL
To: sandra <@cs.utah.edu:sandra@defun>, cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 20 Jan 89 15:53:12 MST
The problem with your position is that it would not let me have
a free local lexical declaration if there were a lexical proclamation
-- or would it? The ammendment made at the meeting was to make local
special declaraions illegal in that case.
-- Jeff
∂23-Jan-89 1640 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Backquote Documentation
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Jan 89 16:40:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 JAN 89 15:37:56 PST
Date: 23 Jan 89 15:36 PST
From: masinter.pa@Xerox.COM
Subject: [Robert S. Boyer <boyer@CLI.COM>: Backquote Documentation
Elaboration]
To: cl-editorial@sail.stanford.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890123-153756-2114@Xerox>
I think this falls into the "editorial" category.
----- Begin Forwarded Messages -----
Return-Path: <boyer@CLI.COM>
Received: from CLI.COM ([10.8.0.62]) by Xerox.COM ; 21 JAN 89 09:17:00 PST
Received: by CLI.COM (4.0/1); Sat, 21 Jan 89 11:12:14 CST
Date: Sat, 21 Jan 89 11:12:14 CST
From: Robert S. Boyer <boyer@CLI.COM>
Message-Id: <8901211712.AA17553@CLI.COM>
To: masinter.pa
Subject: Backquote Documentation Elaboration
Reply-To: boyer@cli.com
On p. 349 of CLTL it states "An implementation is quite free to
interpret backquote in any way such that a backquoted form, when
evaluated, will produce a result equal to that produced by the
interpretation shown here." It should perhaps be emphasized that the
phrase ``when evaluated'' means ``when evaluated in the implementation
of Common Lisp that is currently running'' rather than ``when
evaluated in any correct implementation of Common Lisp''. The
following examples on p. 350 and 351 illustrate alternative results of
backquote reading that use standard Common Lisp functions such as
APPEND, LIST*, etc., but none that use things from, say, package
LUCID-RUNTIME-SUPPORT.
Here is a function that illustrates READ treating backquote
differently in the three Common Lisps I have at hand, using in two
cases functions not defined in CLTL.
(in-package "USER")
(defun which-lisp ()
(let* ((sym (car (read-from-string "`(foo ,y)")))
(package-name (package-name (symbol-package sym))))
(cond ((eq sym 'list) 'kcl)
((equal package-name "SYSTEM-INTERNALS")
'symbolics)
((equal package-name "LUCID-RUNTIME-SUPPORT")
; works in Sun/Lucid 3.0, but not in 2.1
'lucid)
(t 'unknown))))
----- End Forwarded Messages -----
∂23-Jan-89 2027 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Jan 89 20:27:44 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA19278; Mon, 23 Jan 89 21:26:20 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA19262; Mon, 23 Jan 89 21:26:17 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901240426.AA19262@defun.utah.edu>
Date: Mon, 23 Jan 89 21:26:16 MST
Subject: Re: issue PROCLAIM-LEXICAL
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Cc: sandra <sandra%defun@cs.utah.edu>, cl-cleanup@sail.stanford.edu
In-Reply-To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Mon, 23 Jan 89 23:25:50 GMT
> Date: Mon, 23 Jan 89 23:25:50 GMT
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
>
> The problem with your position is that it would not let me have
> a free local lexical declaration if there were a lexical proclamation
> -- or would it? The ammendment made at the meeting was to make local
> special declaraions illegal in that case.
It does seem reasonable that free lexical declarations should just be
no-ops in the presence of a lexical proclamation, but you're right
that the amendment I suggested doesn't allow for that. But I'm not
firmly wedded to that particular language. To repeat what I said
before, my sense from talking to various people between sessions at
the meeting was that the intent of the other amendment was to
guarantee that you'd never be able to reference the global value of a
variable when there's a special binding, but that not everybody was
aware that that amendment didn't actually guarantee what it was
supposed to. Basically, in proposing my amendment, I was just being
obstructionist :-) and trying to prevent taking a vote that we'd end
up regretting once we had time to think about its implications.
I am rather lukewarm on this whole issue. I like the intent of the
latest round of amendments better than the existing proposal, but I'd
be just as happy to leave this feature out of the standard entirely
for now -- it doesn't appear to represent "current practice" and users
seem to have been getting along OK without it.
-Sandra
-------
∂23-Jan-89 2148 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Jan 89 21:48:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 JAN 89 21:47:09 PST
Date: 23 Jan 89 21:45 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue PROCLAIM-LEXICAL
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
Mon, 23 Jan 89 21:26:16 MST
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890123-214709-2907@Xerox>
The proposal mentions in passing "It would be possible to submit a proposal
for a GLOBAL (G) declaration
under separate cover if anyone (Xerox?) was interested."
I'd say that as far as I can tell, with the amendment that local SPECIAL
declarations are not allowed for variables proclaimed lexical, there are
few differences between GLOBAL in Medley and LEXICAL as proposed; the major
difference being that a local LEXICAL declaration will override a global
SPECIAL proclaimation, but in Medley, a local GLOBAL declaration implies
that no lexical bindings are allowed.
Insofar as GLOBAL is very like LEXICAL, it would count for "current
practice", would it not? The reason for GLOBAL is primarily for performance
-- it is a deep-bound implementation, and references to GLOBAL variables
are significantly faster. I don't think Medley users would get along OK
without it. I don't think users of *any* deep-bound implementation would
get along well without some equivalent. While I hate to see special
features put into the standard for idiosyncratic implementation techniques,
deep-binding is not new or idiosyncratic, and this is really the minimal
declaration necessary consistent with current practice.
Given the likelihood of PROCLAIM-LEXICAL:LG failing, I suppose I *would*
like to see a GLOBAL proclaimation made standard, since it doesn't seem to
hurt shallow bound implementations and is important for deep-bound
implementations. If "it is an error to attempt to bind a variable
proclaimed or declared GLOBAL", if you declare it or proclaim it GLOBAL,
you can't have any bindings, whether such bindings would be lexical or
special. In that sense, a GLOBAL variable could be thought of as a subset
of SPECIAL variables which share the "not bindable" property of constants.
∂24-Jan-89 0327 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 5
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 Jan 89 03:27:25 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01267g; Tue, 24 Jan 89 03:22:36 PST
Received: by bhopal id AA04366g; Tue, 24 Jan 89 03:24:57 PST
Date: Tue, 24 Jan 89 03:24:57 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901241124.AA04366@bhopal>
To: sandra%defun@cs.utah.edu
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 20 Jan 89 15:35:50 MST <8901202235.AA17390@defun.utah.edu>
Subject: issue IN-PACKAGE-FUNCTIONALITY, version 5
I don't see the new macro name solving any fundamental problem that is
worth a tremendous incompatible change. In fact, it doesn't even solve
the specification problem, since you would now have to remove the lines
that talked about special treatment (read: evaluation when found at
top-level of compile-file) and add virtually identical lines specifying
what the macro expansion of WITHIN-PACKAGE does.
Beyond that, there are some sections that I have problems with:
re: This macro causes *PACKAGE* to be set to the package named NAME,
When? At macro expansion time? or do you mean it is a trivial
expansion into (setq *package* ...)?
re: . . . Everything this macro does is also
performed at compile time if the call appears at top-level.
Oh really? Then structurally, the specification is identical to IN-PACKAGE?
re: When a compiled file is loaded, the symbols it contains are interned
in the same package they occupied when the file was compiled.
I think I read this as yet another attempt to resurrect the very misleading
plan of compiling symbols out by package-qualifying each and every one of
them. Think about making this requirement on PRINT. Under this rule, it
would be hopeless for a source file and compiled file to "do the same thing",
since the original source had most symbols unqualified, and the "processed"
version had all symbols qualified. Thus in later loadings, the original
source would simply "float" to wherever the current inheritance of symbols
came from; but the "dumped" version would (incompatibly) require them to be
in specific packages. This is too long an issue to debate over the mails,
but I wonder how many readers have themselves gone through the enlightening
phase of trying out "qualify all symbols" and finding the flaws in it?
re: A necessary condition for a program contained in a file to be a
conforming Common Lisp program is that, when the source file is
processed by COMPILE-FILE, all of the symbols in the file be interned
in the same package they would occupy if the source file were
loaded directly with LOAD.
Conforming to what? This statement is incredibly imprecise, since the
packagification of symbols depends on more than simply the text of the
file. For example, what do you mean by "all of the symbols in the
file"? Suppose I have a macro that does something like
(foo x) ==> (internal-subr (list x))
and suppose further I have a file with just the one form (foo 3) in it.
Now, is FOO a symbol in the file? Is INTERNAL-SUBR a symbol in the file?
and what guarantee is there that FOO expands the same way when "in the
compiler" as when running interpretively? [many implementations do
provide a way to find out kludgily whether or not you are "in the
compiler"].
-- JonL --
∂24-Jan-89 1043 CL-Cleanup-mailer Re: issue IN-PACKAGE-FUNCTIONALITY, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 Jan 89 10:43:10 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA08779; Tue, 24 Jan 89 11:41:28 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA19619; Tue, 24 Jan 89 11:41:20 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901241841.AA19619@defun.utah.edu>
Date: Tue, 24 Jan 89 11:41:18 MST
Subject: Re: issue IN-PACKAGE-FUNCTIONALITY, version 5
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, masinter.pa@xerox.com,
cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Tue, 24 Jan 89 03:24:57 PST
> Date: Tue, 24 Jan 89 03:24:57 PST
> From: Jon L White <jonl@lucid.com>
>
> I don't see the new macro name solving any fundamental problem that is
> worth a tremendous incompatible change. In fact, it doesn't even solve
> the specification problem, since you would now have to remove the lines
> that talked about special treatment (read: evaluation when found at
> top-level of compile-file) and add virtually identical lines specifying
> what the macro expansion of WITHIN-PACKAGE does.
The reason why WITHIN-PACKAGE is a macro is because it allows its
special treatment by compile-file to be explained by it expanding into
an EVAL-WHEN, rather than by requiring the compiler to treat it as a
special form. You yourself have argued that this is how other
compile-time magic (such as DEFMACRO) ought to be explained.
> re: This macro causes *PACKAGE* to be set to the package named NAME,
>
> When? At macro expansion time? or do you mean it is a trivial
> expansion into (setq *package* ...)?
>
> re: . . . Everything this macro does is also
> performed at compile time if the call appears at top-level.
>
> Oh really? Then structurally, the specification is identical to IN-PACKAGE?
Well, what I had in mind was something like
(defmacro within-package (name)
`(eval-when (eval compile load)
(setq *package*
(or (find-package ',name)
(error "Package ~s does not exist." ',name)))))
Yes, you're right that the specification is virtually identical to
what the SELECT-ONLY proposal specifies for IN-PACKAGE, except that
WITHIN-PACKAGE is a macro.
> re: When a compiled file is loaded, the symbols it contains are interned
> in the same package they occupied when the file was compiled.
>
> I think I read this as yet another attempt to resurrect the very misleading
> plan of compiling symbols out by package-qualifying each and every one of
> them.
Ummm, this is almost exactly what the cl-compiler issue
CONSTANT-COMPILABLE-TYPES says about symbols ("If the symbol is
interned, its name and the name of its home package identify it"). I
seem to remember that you were one of the people who argued *for*
specifying that particular handling of symbols.
> re: A necessary condition for a program contained in a file to be a
> conforming Common Lisp program is that, when the source file is
> processed by COMPILE-FILE, all of the symbols in the file be interned
> in the same package they would occupy if the source file were
> loaded directly with LOAD.
>
> Conforming to what? This statement is incredibly imprecise, since the
> packagification of symbols depends on more than simply the text of the
> file. For example, what do you mean by "all of the symbols in the
> file"? Suppose I have a macro that does something like
> (foo x) ==> (internal-subr (list x))
> and suppose further I have a file with just the one form (foo 3) in it.
> Now, is FOO a symbol in the file? Is INTERNAL-SUBR a symbol in the file?
I think my statement is at least as precise as the language in CLtL it
replaces, which also includes the phrase about "all the symbols in the
file". If you have some alternative language you would like to propose,
please do so.
-Sandra
-------
∂24-Jan-89 1433 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Jan 89 14:33:30 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 526165; Tue 24-Jan-89 17:31:26 EST
Date: Tue, 24 Jan 89 17:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890124173126.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: DESTRUCTURING-BIND
Forum: Cleanup
References: The LOOP Facility (X3J13/89-004)
Category: ADDITION
Edit history: 24-Jan-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Programmers have frequently requested an interface to a destructuring
bind facility similar to that available in DEFMACRO.
To date, the excuse for not satisfying this request has been a religious
war between factions who want to destructure lists by writing
(DESTRUCTURING-BIND (var1 var2 var3) exp . body)
and those who want to destructure lists by writing
(DESTRUCTURING-BIND (LIST var1 var2 var3) exp . body)
The advantage of the former approach is that it is notationally concise
for the common case of destructuring a list. The disadvantage is that
it is not extensible to accomodate abstract kinds of destructuring.
The advantage of the latter approach is that it allows interesting
extensions that accomodate data-hiding, such as:
(DEFMACRO MAKE-FOO (&REST ELEMENTS) `(LIST ,@ELEMENTS))
(DESTRUCTURING-BIND (MAKE-FOO var1 var2 var3) exp . body)
and later the ability to change the representation of a FOO without
updating the associated binding forms. The disadvantage is that it
is more verbose in the common case of destructuring a list, and still
even more verbose for nested lists.
Destructuring always existed in DEFMACRO, but since forms seen by the
evaluator are generally just lists, rather than arbitrary user-defined
abstract data types, an argument for destructuring of the second kind
in that circumstance seemed like overkill to most people.
Proposal (DESTRUCTURING-BIND:NEW-MACRO):
Provide a macro called DESTRUCTURING-BIND which behaves like the
destructuring bind in DEFMACRO.
(DESTRUCTURING-BIND pattern datum . body)
evaluates datum, binds the indicated pattern variables, and then
executes the body.
Clarify that LOOP does not permit the use of &keywords in its
destructuring, and that proper lists are implicitly `&REST ignore'
(where the variable is quietly ignored).
Test Case:
(DEFUN IOTA (N) (LOOP FOR I FROM 1 TO N COLLECT I)) ;helper
(DESTRUCTURING-BIND ((A &OPTIONAL (B 'BEE)) ONE TWO THREE)
`((ALPHA) ,@(IOTA 3))
(LIST A B THREE TWO ONE))
=> (ALPHA BEE 3 2 1)
Rationale:
Now that LOOP has been introduced into the language with destructuring
of the first kind, rules of internal consistency could be used to
bypass religious arguments in order to satisfy user common needs.
Prior to the introduction of LET into Maclisp, many people wrote their
own LET macros. A popular expansion was in terms of a DO which did not
iterate. eg,
(LET ((A 3)) (+ A A)) ==> (DO ((A 3)) () (RETURN (+ A A)))
While this practice worked, it was not perspicuous and contributed
substantially to non-readability: not only were the macros hard to
understand, but the surface interface itself was not standardized
and varied in subtle ways.
There is now considerable danger that a lot of people will write
DESTRUCTURING-BIND variants in terms of a LOOP expression that
immediately returns.
(DESTRUCTURING-BIND ((A B) C) (FOO) (LIST A B C))
==> (LOOP FOR ((A B) C) ON (FOO) DO (RETURN (LIST A B C)))
We should help to head off the evolution of a number of uselessly
different variants by simply institutionalizing the real support
for this.
Current Practice:
Symbolics Genera already offers this extension.
Cost to Implementors:
Very small. In most cases, it's a matter of renaming and/or exporting an
already existing symbol. In a few cases, a very small amount of
`program interface' code would have to be written.
Cost to Users:
None. This is an upward compatible change.
Cost of Non-Adoption:
Loss of the Benefits and Aesthetics cited below.
Benefits:
Users will get a powerful feature they have asked for on many occassions.
In implementations which `autoload' code, it would be better for this
support to be separable so that people could do DESTRUCTURING-BIND
without demand loading all other LOOP support.
Aesthetics:
Defining this macro centrally will reduce subtle deviations, which will
have positive aesthetic impact.
Defining this facility allows other tools like DEFMACRO and LOOP to be
defined in terms of it. That modularization of description is also a
positive change.
Discussion:
Pitman was on the side of the abstract destructuring and isn't the
slightest bit happy about the kind of destructuring which snuck in
on the `LOOP trojan horse.' However, he thinks something like this
is the rational thing to do at this point. The details are not so
important as coming up with a nice, unified story.
∂24-Jan-89 1527 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 Jan 89 15:27:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 24 JAN 89 15:16:34 PST
Date: 24 Jan 89 15:11 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DESTRUCTURING-BIND (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 24 Jan 89 17:31 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890124-151634-4622@Xerox>
Envos Medley also implements DESTRUCTURING-BIND as specified.
I think we should avoid the characterization "LOOP trojan horse" in the
discussion: if you think this is a problem with LOOP, we should discuss it
under the heading of LOOP. I'd like to avoid giving weight to arguments of
the form "since we let in X, lets let in Y too" since they are potentially
endless.
I think the rationale for this is that it is useful and corresponds to
current practice.
I think the Proposal needs more clarification, "... which behaves like the
destructuring bind in DEFMACRO" being inconsistent with "Clarify that LOOP
does not permit the use of &keywords in its
destructuring, and that proper lists are implicitly `&REST ignore'
(where the variable is quietly ignored)."
In Medley's DESTRUCTURING-BIND, you can use &KEY arguments too.
∂24-Jan-89 1722 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 24 Jan 89 17:22:20 PST
Received: by ti.com id AA04967; Tue, 24 Jan 89 19:21:13 CST
Received: from Kelvin by tilde id AA27299; Tue, 24 Jan 89 19:03:02 CST
Message-Id: <2810682365-5804726@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 24 Jan 89 19:06:05 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: DESTRUCTURING-BIND (Version 1)
In-Reply-To: Msg of Tue, 24 Jan 89 17:31 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> Proposal (DESTRUCTURING-BIND:NEW-MACRO):
>
> Provide a macro called DESTRUCTURING-BIND which behaves like the
> destructuring bind in DEFMACRO.
>
> (DESTRUCTURING-BIND pattern datum . body)
>
> evaluates datum, binds the indicated pattern variables, and then
> executes the body.
...
> Current Practice:
>
> Symbolics Genera already offers this extension.
The TI Explorer also already implements this, although it doesn't
completely match DEFMACRO in that there is no error for wrong number of
arguments or invalid keywords; I'm not sure whether that conforms to the
intent of this proposal or not. It looks like Genera does do error
checking.
I agree that this is a useful feature to have.
∂24-Jan-89 1917 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 Jan 89 19:16:55 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00719g; Tue, 24 Jan 89 19:09:18 PST
Received: by blacksox id AA02442g; Tue, 24 Jan 89 19:11:59 pst
Date: Tue, 24 Jan 89 19:11:59 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901250311.AA02442@blacksox>
To: masinter.pa@Xerox.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 24 Jan 89 15:11 PST <890124-151634-4622@Xerox>
Subject: Issue: DESTRUCTURING-BIND (Version 1)
Lucid CL also implements DESTRUCTURING-BIND.
∂25-Jan-89 0251 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Jan 89 02:51:19 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00850g; Wed, 25 Jan 89 02:45:10 PST
Received: by bhopal id AA07948g; Wed, 25 Jan 89 02:47:30 PST
Date: Wed, 25 Jan 89 02:47:30 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901251047.AA07948@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Tue, 24 Jan 89 17:31 EST <890124173126.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND (Version 1)
Well, foo, I wish someone had thought of this sooner. Clearly, lots
of implementations provide it just as proposed (but in implementation
dependent ways, in order to facilitate error checking). I think this
is a tad too late for CL1989, don't you? double foo.
I also agree with Larry that any motivational reasoning based on LOOP
is a red-herring. DESTRUCTURING-BIND itself would not be so useful in
implementing LOOP as would some underlying functionality that an
implementation of DESTRUCTURING-BIND might use. GSB's portable LOOP
carries around it's own version of destruction (or, the seeds thereof?).
-- JonL --
∂25-Jan-89 0523 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 5
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Jan 89 05:23:26 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00905g; Wed, 25 Jan 89 05:18:41 PST
Received: by bhopal id AA08217g; Wed, 25 Jan 89 05:20:59 PST
Date: Wed, 25 Jan 89 05:20:59 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901251320.AA08217@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 24 Jan 89 11:41:18 MST <8901241841.AA19619@defun.utah.edu>
Subject: issue IN-PACKAGE-FUNCTIONALITY, version 5
re: > Conforming to what? This statement is incredibly imprecise, since the
> packagification of symbols depends on more than simply the text of the
> file. For example, what do you mean by "all of the symbols in the
> file"? Suppose I have a macro that does something like
> (foo x) ==> (internal-subr (list x))
> and suppose further I have a file with just the one form (foo 3) in it.
> Now, is FOO a symbol in the file? Is INTERNAL-SUBR a symbol in the file?
I think my statement is at least as precise as the language in CLtL it
replaces, which also includes the phrase about "all the symbols in the
file". If you have some alternative language you would like to propose,
please do so.
Well, I might love to work on this problem, Sandra, but I do have other
responsibilities. Yes, I agree that CLtL is "incredibly imprecise"
about the semantics of compiling out symbols; but that is no excuse
to jump from the frying pan into the fire. [In fact, I don't think
any single issue has caused more trouble amongst even wizard Lisp
users as this one -- the re-internment of symbols into a "new"
image by a compiled file.]
re: > I think I read this as yet another attempt to resurrect the very
> misleading plan of compiling symbols out by package-qualifying each
> and every one of them.
Ummm, this is almost exactly what the cl-compiler issue
CONSTANT-COMPILABLE-TYPES says . . . I
seem to remember that you were one of the people who argued *for*
specifying that particular handling of symbols.
Absolutely not! You must be thinking of someone else. The last time
this was discussed on Common-Lisp@SAIL, I remember RWK supporting the
position I held -- and for similar reasons; but not many others did.
-- JonL --
∂25-Jan-89 0840 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Jan 89 08:40:40 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 526592; Wed 25-Jan-89 11:38:39 EST
Date: Wed, 25 Jan 89 11:38 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890125113840.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
I've reorganized/rewritten this per discussion thus far.
If you disagree with something, simply identify your disagreement
or (preferrably) propose a change that would make you happy.
Many of the positions in this proposal are just straw men, so
don't waste your time arguing with me because I may not disagree.
The particular points where I most expect disagreement and need
advice on how to proceed are:
- How to clarify LOOP destructuring. Its writeup is currently
too vague. We could spawn a separate issue if discussion gets
out of hand, but there is scheduling overhead to doing so.
If the issue can be handled simply as a paragraph riding
on this proposal, I'd prefer that.
- How much error checking should DESTRUCTURING-BIND do. I'd
personally prefer it always signal on mismatch, but I didn't
write that into the proposal because I wanted to start by
accomodating current practice. If you feel strongly that the
proposal as stated is too tight or too loose, please say so.
-----
Issue: DESTRUCTURING-BIND
Forum: Cleanup
References: DEFMACRO (CLtL pp145-151),
The LOOP Facility (X3J13/89-004)
Category: ADDITION
Edit history: 24-Jan-89, Version 1 by Pitman
25-Jan-89, Version 2 by Pitman
Status: For Internal Discussion
Problem Description:
Common Lisp programmers have frequently complained that the
destructuring facility used by DEFMACRO is not made available
for use in ordinary programming situations involving list data.
The presence of a destructuring facility in the recently adopted
LOOP facility will be likely to make the absence of a separable
destructuring facility all the more apparent.
Prior to the introduction of LET into Maclisp, many people wrote
their own LET macros. A popular expansion was in terms of a DO
which did not iterate. eg,
(LET ((A 3)) (+ A A)) ==> (DO ((A 3)) () (RETURN (+ A A)))
While this practice `worked,' it was not perspicuous and contributed
substantially to non-readability: not only were the macros hard to
understand, but the surface interface itself was not standardized
and varied in subtle ways. For example, some LET macros allowed GO
statements while others did not.
There is now considerable danger that a lot of people will write
DESTRUCTURING-BIND variants in terms of a LOOP expression that
immediately returns.
(DESTRUCTURING-BIND ((A B) C) (FOO) (LIST A B C))
==> (LOOP FOR ((A B) C) ON (FOO) DO (RETURN (LIST A B C)))
Since the destructuring offered by LOOP is different in subtle ways
from the destructuring offered by DESTRUCTURING-BIND in implementations
offering that primitive natively, gratuitous headaches could result.
Proposal (DESTRUCTURING-BIND:NEW-MACRO):
Provide a macro called DESTRUCTURING-BIND which behaves like the
destructuring bind in DEFMACRO. Specifically...
DESTRUCTURING-BIND lambda-list expression {decl|doc}* {form}* [Macro]
Binds the variables specified in LAMBDA-LIST to the corresponding
values in the tree structure resulting from evaluating EXPRESSION,
then evaluates the FORMS in the body.
Anywhere in the LAMBDA-LIST where a parameter name may appear, and
where ordinary lambda-list syntax (as described in CLtL section 5.2.2)
does not otherwise allow a list, a lambda-list may appear in place of
the parameter name. When this is done, then the argument form that
would match the parameter is treated as a (possibly dotted) list, to
be used as an argument forms list for satisfying the parameters in
the embedded lambda-list.
If any of the lambda list keywords &OPTIONAL, &REST, &KEY,
&ALLOW-OTHER-KEYS and &AUX appears in the lambda list, it is treated
as with any other lambda-list.
If the lambda list keyword &BODY appears, it is treated as a synonym
for &REST.
If the lambda list keyword &WHOLE appears, it must be followed by a
single variable that is bound to the entire expression at the current
level. &WHOLE and the following variable should appear first in the
list, before any other parameter or lambda-list keyword.
It is also permissible for any level of the LAMBDA-LIST to be dotted,
ending in a parameter name. This situation is treaed exactly as if
the aprameter name that ends the list had appeared preceded by &REST
in a proper list. For example, the notation (X Y . Z) is equivalent
to (X Y &REST Z).
If the result of evaluating the expression does not match the
destructuring pattern, the consequences are undefined. Implementations
are not required to signal an error in this case, but neither are they
permitted to extend the behavior by defining it to be harmless.
Clarify that the destructuring done by LOOP does not permit the use of
any lambda-list-keywords. Further clarify that in LOOP, proper lists
are implicitly `&REST var' (where the non-use of var is quietly ignored).
Hence, it is permissible to have:
(LOOP FOR (X Y) ON '(A B C D) COLLECT (CONS X Y)) => ((A . B) (C . D))
but it is not permissible to have:
(DESTRUCTURING-BIND (X Y) '(A B C D) (CONS X Y))
since the pattern does not match. One must instead write:
(DESTRUCTURING-BIND (X Y &REST Z) '(A B C D)
(DECLARE (IGNORE Z))
(CONS X Y))
Test Case:
(DEFUN IOTA (N) (LOOP FOR I FROM 1 TO N COLLECT I)) ;helper
(DESTRUCTURING-BIND ((A &OPTIONAL (B 'BEE)) ONE TWO THREE)
`((ALPHA) ,@(IOTA 3))
(LIST A B THREE TWO ONE))
=> (ALPHA BEE 3 2 1)
Rationale:
The proposal directly addresses the stated problem, and is current practice
in numerous implementations. Our charter effectively dictates that where
feasible we should try to head off the widespread development of uselessly
different variants of commonplace tools.
Current Practice:
Symbolics Genera, Envos Medley, TI Explorer, and Lucid CL all offer
DESTRUCTURING-BIND, though the details vary slightly.
The DESTRUCTURING-BIND offered by Symbolics Genera signals an error if
the pattern is not matched. The TI Explorer version does not.
Cost to Implementors:
Very small. In most cases, it's a matter of renaming and/or exporting an
already existing symbol. In a few cases, a very small amount of
`program interface' code would have to be written.
Cost to Users:
None. This is an upward compatible change.
Cost of Non-Adoption:
Loss of the Benefits and Aesthetics cited below.
Benefits:
Users will get a powerful feature they have asked for on many occassions.
In implementations which `autoload' code, it would be better for this
support to be separable so that people could do DESTRUCTURING-BIND
without demand loading all other LOOP support.
Aesthetics:
Defining this macro centrally for the Common Lisp community will reduce
subtle deviations, which will in turn have positive aesthetic impact.
Discussion:
JonL observes that although LOOP does destructuring, it can't directly
make use of the DESTRUCTURING-BIND interface suggested here.
Pitman and Gray think a facility of this sort is a good idea, though
obviously the details may still need a little fleshing out before the
proposal is ready for vote.
To date, the excuse for not satisfying this request has been a
religious war between factions who want to destructure lists by
writing
(DESTRUCTURING-BIND (var1 var2 var3) exp . body)
and those who want to destructure lists by writing
(DESTRUCTURING-BIND (LIST var1 var2 var3) exp . body)
The advantage of the former approach is that it is notationally
concise for the common case of destructuring a list. The disadvantage
is that it is not extensible to accomodate abstract kinds of
destructuring.
The advantage of the latter approach is that it allows interesting
extensions that accomodate data-hiding, such as:
(DEFMACRO MAKE-FOO (&REST ELEMENTS) `(LIST ,@ELEMENTS))
(DESTRUCTURING-BIND (MAKE-FOO var1 var2 var3) exp . body)
and later the ability to change the representation of a FOO without
updating the associated binding forms. The disadvantage is that it
is more verbose in the common case of destructuring a list, and still
even more verbose for nested lists.
Although destructuring has always existed in DEFMACRO, this has not
been adequate precedence for deciding the outcome of the religious war
because DEFMACRO only needs to destructure programs, and programs are
generally made up only of lists -- not arbitrary user-defined abstract
data types.
∂25-Jan-89 1018 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 25 Jan 89 10:18:34 PST
Received: from fafnir.think.com by Think.COM; Wed, 25 Jan 89 12:53:50 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 25 Jan 89 13:15:10 EST
Received: from joplin.think.com by verdi.think.com; Wed, 25 Jan 89 13:13:57 EST
Received: by joplin.think.com; Wed, 25 Jan 89 13:15:02 EST
Date: Wed, 25 Jan 89 13:15:02 EST
From: gls@Think.COM
Message-Id: <8901251815.AA02702@joplin.think.com>
To: jonl@lucid.com
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Wed, 25 Jan 89 02:47:30 PST <8901251047.AA07948@bhopal>
Subject: Issue: DESTRUCTURING-BIND (Version 1)
"And you tell meeeeeee
Over and over and over and over again,
My friend,
That you dont't believe
We're on the eve
Of destruction?"
--(sorry, can't remember name of composer or recording artist)
--Quux
∂25-Jan-89 1111 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 Jan 89 11:11:04 PST
Received: from Semillon.ms by ArpaGateway.ms ; 25 JAN 89 10:55:33 PST
Date: 25 Jan 89 10:50 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DESTRUCTURING-BIND (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Wed, 25 Jan 89
02:47:30 PST
To: Jon L White <jonl@lucid.com>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890125-105533-6432@Xerox>
It's not over until the committee sings, is it?
I don't think the rationale for *passing* this issue should be "consistency
with LOOP", but I do think that's the rationale for *bringing up* this
issue. The Rationale section should document the reasons why the changes
we are making are good changes. The reason this is a good change is that it
is not only useful, it is current practice in many implementations, and,
it is consistent with LOOP, in that order.
The reason for bringing it up now (which we might mention in the Discussion
section) is that LOOP reminded us of it, and the fact that LOOP can be used
for the same thing pushes things over the edge.
I don't think this is a big deal, but am a little sensitive that the
changes we make should be "right" judged independently of our schedule,
even though we stick to the schedule.
∂25-Jan-89 1111 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 Jan 89 11:11:09 PST
Received: from Semillon.ms by ArpaGateway.ms ; 25 JAN 89 10:55:36 PST
Date: 25 Jan 89 10:52 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DESTRUCTURING-BIND (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Wed, 25 Jan 89
02:47:30 PST
To: Jon L White <jonl@lucid.com>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890125-105536-6433@Xerox>
I should read all my mail before answering... I'll look over Kent's new
version before commenting further.
∂25-Jan-89 1604 CL-Cleanup-mailer Issue status-- not 'till next week
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 Jan 89 16:04:31 PST
Received: from Semillon.ms by ArpaGateway.ms ; 25 JAN 89 15:57:43 PST
Date: 25 Jan 89 15:56 PST
From: masinter.pa@Xerox.COM
Subject: Issue status-- not 'till next week
To: cl-cleanup@sail.stanford.edu
Message-ID: <890125-155743-7374@Xerox>
I'll be sorting out my list of issues & new versions next week sometime;
there's some stuff I've put off for the last month I need to get to.
I'd like some help getting together "release" versions of the issues that
were amended, if you are so inclined.
∂25-Jan-89 1711 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 25 Jan 89 17:09:47 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05955; 25 Jan 89 16:17 GMT
Date: Wed, 25 Jan 89 16:26:36 GMT
Message-Id: <20300.8901251626@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue PROCLAIM-LEXICAL
To: masinter.pa@xerox.com, sandra <@cs.utah.edu:sandra@defun>
In-Reply-To: masinter.pa@com.xerox's message of 23 Jan 89 21:45 PST
Cc: cl-cleanup@sail.stanford.edu
> The proposal mentions in passing "It would be possible to submit a proposal
> for a GLOBAL (G) declaration
> under separate cover if anyone (Xerox?) was interested."
I'm still not quite happy with GLOBAL, particularly if it disallows
local lexical variables of the same name. As far as lexical variables
are concerned, the reference can be determined statically. And if it's
to the global, it's to the global. No efficiceny need be lost. That's
what happens in languages without special variables, and it's what
should happen in Lisp for variables that are lexical. So I don't
think the LG proposal had much need for a GLOBAL declaration.
As I understand it, the problem faced by deep-bound implementations
(of special variables) is that they don't know whether there are
any bindings or not and so have to look before fetching the global
value. But I think it's OK for that to happen to variables that
might have special bindings; what's wrong is to have to do it even
though the programmer knows there will never be any bindings.
So if GLOBAL is taken to mean only "there will be no special
bindings", then it's probably OK.
Some implementations allow one to fetch the global value even
thought there are local special bindings. I think such usage
represents a confusion about whether the variable is supposed
to have special bindings or not.
Nonetheless, although I think a limited meaning for GLOBAL is ok,
I still prefer LEXICAL. LEXICAL sunsumes all the reasonable uses
of GLOBAL.
∂26-Jan-89 1215 CL-Cleanup-mailer Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Jan 89 12:15:37 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 527498; Thu 26-Jan-89 15:13:14 EST
Date: Thu, 26 Jan 89 15:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890126151314.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Trust me. You're gonna love this one! -kmp
-----
Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION
Forum: Cleanup
References: *PRINT-ESCAPE* (pp370-371), *PRINT-CASE* (pp372), WRITE
Category: CLARIFICATION
Edit history: 26-Jan-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The wording on page 372 of CLtL uses fuzzy terms that make it hard
to tell if *PRINT-ESCAPE* interacts with *PRINT-CASE*.
Paragraph 1 of the description of *PRINT-CASE* says "This variable
controls the case (upper, lower, or mixed) in which to print any
uppercase characters in the names of symbols when vertical-bar
syntax is used."
Paragraph 2 begins with the seemingly unambiguous statement "Lowercase
characters in the internal print name are always printed in lowercase"
but then goes on to muddy the water by saying "and are preceded by
a single escape character or enclosed by multiple escape characters".
This escaping presumably only happens in *PRINT-ESCAPE* T mode, which
leads one to wonder if other parts of the *PRINT-ESCAPE* description are
implicitly controlled by *PRINT-ESCAPE* as well.
The function WRITE is affected by implication.
Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:LIKE-PRIN1):
Define that *PRINT-CASE* cases characters the same as PRIN1 would.
Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:LIKE-WRITE-STRING):
Define that *PRINT-CASE* has an effect only when *PRINT-ESCAPE* is T.
When *PRINT-CASE* is NIL, WRITE-STRING is used directly.
Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-NO-UPCASE):
Define that *PRINT-CASE* has an effect at all times when *PRINT-ESCAPE*
is NIL. Define that *PRINT-CASE* also has an effect when *PRINT-ESCAPE*
is T unless inside an escape context (i.e., unless between vertical bars
or after a slash). Under no circumstance is any character which was
lowercase in the internal representation ever presented as uppercase
due to *PRINT-CASE*.
Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-PERMIT-UPCASE):
Like VERTICAL-BAR-RULE-NO-UPCASE, but permit *PRINT-CASE* to upcase
lowercase characters in the *PRINT-ESCAPE* NIL case since preservation of
Lisp syntax is not important there.
Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:EXPLICITLY-VAGUE):
Specify that the effect of *PRINT-CASE* when *PRINT-ESCAPE* is NIL
is implementation-dependent.
Test Case:
(LET ((RESULT '()) (TABWIDTH 12))
(DOLIST (SYMBOL '(|x| |FoObAr| |fOo|))
(LET ((TAB -1))
(FORMAT T "~&")
(DOLIST (ESCAPE '(T NIL))
(DOLIST (CASE '(:UPCASE :DOWNCASE :CAPITALIZE))
(FORMAT T "~VT" (* (INCF TAB) TABWIDTH))
(WRITE SYMBOL :ESCAPE ESCAPE :CASE CASE))))))
For each of the following, two clusters of output is shown. The first is
how an implementation which leans heavily on vertical bars might work.
The second is how an implementation which leans heavily on slash might
work. In fact, other interpretations are possible (mixing slash and
vertical bar). These examples are not an exhaustive analysis of the
implications of each proposal.
Possible outputs under LIKE-PRIN1:
|x| |x| |x| x x x
|FoObAr| |FoObAr| |FoObAr| FoObAr FoObAr FoObAr
|fOo| |fOo| |fOo| fOo fOo fOo
\x \x \x x x x
F\oO\bA\r f\oo\ba\r F\oo\ba\r FoObAr foobar Foobar
\fO\o \fo\o \fo\o fOo foo foo
Possible output under LIKE-WRITE-STRING:
|x| |x| |x| x x x
|FoObAr| |FoObAr| |FoObAr| FoObAr FoObAr FoObAr
|fOo| |fOo| |fOo| fOo fOo fOo
\x \x \x x x x
F\oO\bA\r f\oo\ba\r F\oo\ba\r FoObAr FoObAr FoObAr
\fO\o \fo\o \fo\o fOo fOo fOo
Possible output under VERTICAL-BAR-RULE-NO-UPCASE:
|x| |x| |x| x x x
|FoObAr| |FoObAr| |FoObAr| FoObAr foobar Foobar
|fOo| |fOo| |fOo| fOo foo foo
\x \x \x x x x
F\oO\bA\r f\oo\ba\r F\oo\ba\r FoObAr foobar Foobar
\fO\o \fo\o \fo\o fOo foo foo
Possible output under VERTICAL-BAR-RULE-PERMIT-UPCASE:
|x| |x| |x| X x X
|FoObAr| |FoObAr| |FoObAr| FOOBAR foobar Foobar
|fOo| |fOo| |fOo| FOO foo Foo
\x \x \x X x X
F\oO\bA\r f\oo\ba\r F\oo\ba\r FOOBAR foobar Foobar
\fO\o \fO\o \fO\o FOO foo Foo
Rationale:
It's silly for implementations to vary on this point.
Current Practice:
A strict reading of CLtL suggests that probably VERTICAL-BAR-RULE-NO-UPCASE
is the most correct.
Symbolics Genera doesn't do any of these. It was trying to do
VERTICAL-BAR-NO-UPCASE, but it had a bug which was about to be fixed when
this issue was raised.
Cost to Implementors:
Probably trivial.
Cost to Users:
Negligible in most cases. Probably very few users depend on this.
Those who do depend on it probably do so because they think the
behavior doesn't vary and probably don't get the portable behavior they
expect.
Cost of Non-Adoption:
Gratuitous variation between implementations.
Benefits:
Cost of non-adoption is avoided.
Aesthetics:
Anything that makes the language tighter probably improves aesthetics.
Only VERTICAL-BAR-RULE-PERMIT-UPCASE and LIKE-WRITE-STRING have really
useful behaviors in the :ESCAPE NIL situation. Of these, perhaps only
VERTICAL-BAR-RULE-PERMIT-UPCASE is really visually pleasant.
Discussion:
Pitman doesn't think the particular choice is very important. He just
wants the issue to be resolved. His slight preference is for
VERTICAL-BAR-RULE-PERMIT-UPCASE, then LIKE-WRITE-STRING, then either
of LIKE-PRIN1 or VERTICAL-BAR-RULE-NO-UPCASE. He sees no reason to go
with EXPLICITLY-VAGUE unless we deadlock.
Michael Greenwald, who raised the issue at Symbolics, doesn't have
a preference either but believes that CLtL (perhaps unintentionally)
leans toward VERTICAL-BAR-RULE-NO-UPCASE.
∂27-Jan-89 0326 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Jan 89 03:25:55 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA13714g; Fri, 27 Jan 89 03:20:40 PST
Received: by bhopal id AA17677g; Fri, 27 Jan 89 03:22:55 PST
Date: Fri, 27 Jan 89 03:22:55 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901271122.AA17677@bhopal>
To: masinter.pa@Xerox.COM
Cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 23 Jan 89 21:45 PST <890123-214709-2907@Xerox>
Subject: issue PROCLAIM-LEXICAL
re: Insofar as GLOBAL is very like LEXICAL, it would count for "current
practice", would it not? The reason for GLOBAL is primarily for performance
-- it is a deep-bound implementation, and references to GLOBAL variables
are significantly faster. I don't think Medley users would get along OK
without it. I don't think users of *any* deep-bound implementation would
Quite right. You can also add to current practice that QLISP uses a
GLOBAL declaration in just about the same way that Interlisp-D/Medley
does. [It was probably my comment in the Discussion that you referred to
when you said "It would be possible to submit a proposal for a GLOBAL (G)
declaration under separate cover if anyone (Xerox?) was interested."]
I think QLISP would find acceptable the minor adjustment about allowing
purely local lexical rebinding of proclaimed GLOBAL's. Surely Medley
would have no trouble accommodating either.
-- JonL --
P.S. QLISP is a research prototype of Lucid Common Lisp running on a
certain parallel processor. It uses deep-binding for the obvious
reason. By the bye, "research prototype" doesn't mean "it's a dog";
there is some serious research being conducted using QLISP as a tool.
∂27-Jan-89 1755 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 89 17:55:15 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 528632; Fri 27-Jan-89 20:51:01 EST
Date: Fri, 27 Jan 89 20:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue PROCLAIM-LEXICAL
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, masinter.pa@Xerox.COM,
Jon L White <jonl@lucid.com>
cc: cl-cleanup@SAIL.STANFORD.EDU, sandra <@cs.utah.edu:sandra@defun>
In-Reply-To: <8901202253.AA17398@defun.utah.edu>,
<890123132952.8.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<14006.8901232325@subnode.aiai.ed.ac.uk>,
<8901240426.AA19262@defun.utah.edu>,
<890123-214709-2907@Xerox>,
<20300.8901251626@subnode.aiai.ed.ac.uk>,
<8901271122.AA17677@bhopal>
Message-ID: <19890128015132.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Fri, 20 Jan 89 15:53:12 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
My gut feeling on this issue is that people would be willing to vote
it in, provided that we can guarantee that you would never have to
access the symbol's global value when there is a special binding of
the variable. I believe this was the purpose of the amendment that
was accepted (stating that "it is an error" to specially bind a variable
that has been proclaimed lexical), but there are still some other
possible cases.
Yes, I believe that was the unstated goal behind all of the proposed
amendments. I also believe that it would take several additional
amendments beyond the two proposed to completely close this "hole."
I agree with Kent that trying to close this "hole" is a very, very bad
idea.
I believe that the reason people have this goal is not at all an issue
of desired language semantics, but instead that they believe it would be
too difficult in a shallow-bound implementation to allow access to the
global value in the presence of special bindings. I used to believe
that too, but I figured out that the implementation expense can be very
small. Here is why:
On stock hardware, the implementation of special variables is unchanged
except that associated with each shallow binding cell is a flag that
says whether a SPECIAL binding has ever been performed. This flag can
be set by the loader when a function that might make a SPECIAL binding
of that variable is loaded, and also must be set by PROGV. The
implementation of global LEXICAL variables checks this flag; if clear
(as it will be in the vast majority of cases), use the shallow binding
cell. If the flag is set, global LEXICAL access must search the SPECIAL
binding information to find where the global value has been saved, a
pleasing symmetry with deep binding. Note that this implementation puts
100% of the performance cost on the new feature, and in the majority of
cases the performance cost is only two instructions to verify that the
flag is clear. In fact, in an implementation that can patch compiled
code, the cost is zero because global LEXICAL accesses can be compiled
optimistically and in the event that the SPECIAL binding flag gets set,
they can be patched to call the slow subroutine. Of course in a deep
bound implementation, global LEXICAL access just accesses the global
cell and there is no cost.
On machines with invisible pointers, the implementation is to have a
global SPECIAL cell and a separate global LEXICAL cell, linked together
by an invisible pointer from the SPECIAL cell to the LEXICAL cell.
SYMBOL-VALUE and SET follow the invisible pointer, but binding does not.
As desired, the shallow bound cell shares with the global LEXICAL cell if
and only if no special bindings are present. Of course you only create
these value cells on demand, so for the vast majority of symbols that
are not used in both the SPECIAL way and the global LEXICAL way, you do
not pay the overhead of having two cells.
My conclusion is that I am strongly opposed to any attempt to amend this
proposal to restrict simultaneous use of special and lexical variables.
It would be much preferable not to pass this proposal at all than to
pass it in messed-up form.
Date: 23 Jan 89 21:45 PST
From: masinter.pa@Xerox.COM
....The reason for GLOBAL is primarily for performance
-- it is a deep-bound implementation, and references to GLOBAL variables
are significantly faster. I don't think Medley users would get along OK
without it. I don't think users of *any* deep-bound implementation would
get along well without some equivalent.
I think the idea that deep-bound implementations can only work well when
there are GLOBAL declarations is misguided. What does GLOBAL really
mean? I claim it is a -declaration- by which the programmer promises
not to make any special bindings. But the implementation is perfectly
capable of determining for itself whether there are any special
bindings, without any help from the programmer. Comparable to what I
suggested above for LEXICAL variables in shallow-bound implementations,
accessing a SPECIAL variable in a deep-bound implementation can easily
check a flag indicating whether any bindings have ever been performed.
In the usual case where there are no bindings, the run-time cost is
zero, as I indicated above.
Given the likelihood of PROCLAIM-LEXICAL:LG failing, I suppose I *would*
like to see a GLOBAL proclaimation made standard, since it doesn't seem to
hurt shallow bound implementations and is important for deep-bound
implementations. If "it is an error to attempt to bind a variable
proclaimed or declared GLOBAL", if you declare it or proclaim it GLOBAL,
you can't have any bindings, whether such bindings would be lexical or
special. In that sense, a GLOBAL variable could be thought of as a subset
of SPECIAL variables which share the "not bindable" property of constants.
In the immortal words of America's last truly great president, we could do
that but it would be wrong.
I think we should pass PROCLAIM-LEXICAL as it was before it was amended.
Date: Wed, 25 Jan 89 16:26:36 GMT
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
As I understand it, the problem faced by deep-bound implementations
(of special variables) is that they don't know whether there are
any bindings or not and so have to look before fetching the global
value. But I think it's OK for that to happen to variables that
might have special bindings; what's wrong is to have to do it even
though the programmer knows there will never be any bindings.
Right, that's what I was trying to say above.
I still prefer LEXICAL. LEXICAL sunsumes all the reasonable uses
of GLOBAL.
I feel the same way.
∂27-Jan-89 1803 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 89 18:03:19 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 528636; Fri 27-Jan-89 21:01:24 EST
Date: Fri, 27 Jan 89 21:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <890125113840.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890128020158.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support version 2 of this. I have a couple of minor comments:
DESTRUCTURING-BIND should not allow &WHOLE any more than it should allow
&ENVIRONMENT. Those two features are specific to macroexpanders.
Both LOOP and DESTRUCTURING-BIND allow NIL in place of a variable
name as a way of ignoring a portion of the destructured tree, in
Symbolics current practice. I think that's a good idea and should
go in the standard. It's only an abbreviation for a dummy variable
and a DECLARE IGNORE, but the whole destructuring feature is
nothing but an abbreviation anyway.
∂27-Jan-89 1805 CL-Cleanup-mailer Issue: LISP-PACKAGE-NAME, (Version 1)
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 27 Jan 89 18:05:03 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Fri, 27 Jan 89 20:03:20 CST id AA07228 for cl-cleanup@sail.stanford.edu
Posted-Date: Fri, 27 Jan 89 20:01:47 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA03960; Fri, 27 Jan 89 20:01:47 CST
Date: Fri, 27 Jan 89 20:01:47 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8901280201.AA03960@pavo.src.honeywell.com>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 11 Jan 89 16:52 PST <890111-165258-11168@Xerox>
Subject: Issue: LISP-PACKAGE-NAME, (Version 1)
I have two comments with regard to this proposal; first, it should mention
the user package (perhaps cl-user), secondly there is a much simpler way to
get print/read inconsistency than that described in the proposal, just have
*PACKAGE* bound to a package that does not use CL be current when printing.
I would feel better requiring CL:SYMBOL-PACKAGE returning the CL package
for symbols defined in the spec.
∂27-Jan-89 1824 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Jan 89 18:24:20 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA01066g; Fri, 27 Jan 89 18:17:44 PST
Received: by blacksox id AA00103g; Fri, 27 Jan 89 18:19:47 pst
Date: Fri, 27 Jan 89 18:19:47 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901280219.AA00103@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Fri, 27 Jan 89 21:01 EST <19890128020158.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND (Version 2)
Date: Fri, 27 Jan 89 21:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Both LOOP and DESTRUCTURING-BIND allow NIL in place of a variable
name as a way of ignoring a portion of the destructured tree, in
Symbolics current practice. I think that's a good idea and should
go in the standard. It's only an abbreviation for a dummy variable
and a DECLARE IGNORE, but the whole destructuring feature is
nothing but an abbreviation anyway.
Should NIL be allowed in DEFMACRO argument lists also?
∂27-Jan-89 1844 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 89 18:44:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 528651; Fri 27-Jan-89 21:41:30 EST
Date: Fri, 27 Jan 89 21:42 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue IN-PACKAGE-FUNCTIONALITY, version 5
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: masinter.pa@xerox.com, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8901202235.AA17390@defun.utah.edu>
Message-ID: <19890128024204.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I fully agree with the first part of this proposal (remove IN-PACKAGE,
add WITHIN-PACKAGE). Like JonL, I disagree with the second part (what
COMPILE-FILE does with symbols). Part of the problem is it uses the
words "interned" and "occupied" which are not given precise definitions.
Here is a suggested recasting of that paragraph of your proposal using
the words defined at the beginning of the chapter:
When a compiled file is loaded, the interned symbols it references
are found by the following procedure. The rules are applied in the
order listed and only the first applicable rule has any effect.
(1) The distinguished empty list symbol NIL retains its identity.
(2) Any symbol accessible at compile time in the package that is the
value of *PACKAGE* is found by calling INTERN at load time with one
argument, the name of the symbol.
(3) A keyword symbol is found by finding or creating a keyword
symbol with the same name.
(4) A symbol that at compile time is an external symbol of its home
package is found at load time by finding the package with the same
name as the compile-time home package, and then finding an exported
symbol of that package with the same name as the compile-time
symbol. If no such package exists, no such symbol exists, or the
symbol is not exported, an error is signalled.
(5) Any other symbol is found by calling INTERN at load time with
two arguments, the name of the symbol and the package with the same
name as the compile-time symbol's home package. If no such package
exists, an error is signalled.
The goal of this procedure is for each symbol reference to be
resolved to the same symbol when a compiled file is loaded as when
the source file is loaded directly with LOAD. It is possible to
create package structures that make that impossible; for example, it
is possible for a symbol to be inaccessible from its own home
package. A conforming program cannot depend on any symbol
resolution behavior that is not provided by the above five rules.
If any top level form in a compiled file changes the value of
*PACKAGE*, other than a WITHIN-PACKAGE appearing as the first
effective top level form in the file, the results are unspecified.
[What I mean by "effective top level form" is to include x in
constructs like (PROGN x ...) and macros that expand into x. Do you
compiler people have a name for this? That is, a WITHIN-PACKAGE
must be the first top level form that has any effect.]
Perhaps this should be a separate proposal from IN-PACKAGE-FUNCTIONALITY?
∂27-Jan-89 1950 CL-Cleanup-mailer Issue: FUNCTION-NAME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 89 19:49:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 528674; Fri 27-Jan-89 22:47:46 EST
Date: Fri, 27 Jan 89 22:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-NAME (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU
Message-ID: <19890128034814.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here is the new proposal for the SETF issue that I put up on slides at
the X3J13 meeting. It's been refined a bit, according to the
suggestions various people made.
Assuming this remains in the Cleanup subcommittee, perhaps Larry should
put this on the forthcoming letter ballot so we don't necessarily have
to wait until March to deal with it.
Issue: FUNCTION-NAME
References: SETF rules for what -place- can be (pp.94-7)
FBOUNDP function (p.90)
FMAKUNBOUND function (p.92)
FUNCTION special form (p.87)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
88-002R pages 1-21, 2-21, 2-26, 2-39, 2-44, 2-46, 2-51, and 2-55
(There are additional references for the MEDIUM and LARGE
proposals, but they are not listed here. They're obvious.)
Related issues: SETF-FUNCTION-VS-MACRO, SETF-PLACES (both subsumed by this)
Category: ADDITION
Edit history: Version 1, 23-Jan-89, by Moon
(based on discussion at X3J13 meeting)
Problem description:
The Common Lisp Object System needs a well-defined way to relate the name
and arguments of a writer function to those of a reader function, because
both functions can be generic and can have user-defined methods. The way
that was adopted into Common Lisp when X3J13 voted to accept document
88-002R was to use a list (SETF reader) as the name of the writer function.
Some changes to the non-object-oriented portion of Common Lisp are required
in order to support this.
This issue has three proposals.
Proposal (FUNCTION-NAME:SMALL):
Add a new concept "function-name" (called "function-specifier" in
88-002R). A function-name is either a symbol or a 2-element list whose
first element is the symbol SETF and whose second element is a symbol.
Implementations are free to extend the syntax of function-names to
include lists beginning with additional symbols other than SETF.
Add a new function (FDEFINITION function-name), which returns the
current global function definition named by function-name, or signals
an error if there is no global function definition. This follows all
the same rules listed for SYMBOL-FUNCTION in CLtL p.90.
Add SETF of FDEFINITION to change the current global function definition
named by a function-name. This follows all the same rules listed for
SETF of SYMBOL-FUNCTION in CLtL p.90.
Change the FBOUNDP and FMAKUNBOUND functions, and the FUNCTION special
form, to accept function-names in place of symbols. Implementation
defined extensions to the syntax of function-names cannot use the
symbol LAMBDA, since FUNCTION already uses that symbol.
Change the rules for SETF places (CLtL pp.94-7) by adding the following
clause after all the existing clauses:
- Any other list whose first element is a symbol, call it reader.
In this case, SETF expands into a call to the function named by the
list (SETF reader). The first argument is the new value and the
remaining arguments are the values of the remaining elements of
-place-. This expansion occurs regardless of whether reader or
(SETF reader) is defined as a function locally, globally, or not at
all. For example,
(SETF (reader arg1 arg2...) new-value)
expands into a form with the same effect and value as
(LET ((#:temp-1 arg1) ;force correct order of evaluation
(#:temp-2 arg2)
...
(#:temp-0 new-value))
(FUNCALL (FUNCTION (SETF reader)) #:temp-0 #:temp-1 #:temp-2...)).
Change the functions GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE
to implement the above change to the rules.
Document that a function named (SETF reader) should return its first
argument as its only value, in order to preserve the semantics of SETF.
Change the macro DEFGENERIC and the function ENSURE-GENERIC-FUNCTION to
refer to the function FDEFINITION where they now refer to the function
SYMBOL-FUNCTION.
Change the macros DEFCLASS, DEFGENERIC, and DEFMETHOD, the special forms
GENERIC-FLET and GENERIC-LABELS, and the functions DOCUMENTATION and
ENSURE-GENERIC-FUNCTION to use the term "function-name" where they now
use the term "function-specifier" or "function specifier".
Rationale for FUNCTION-NAME:SMALL:
This is the minimum change to Common Lisp needed to do what 88-002R says
about (SETF reader). Giving implementations freedom to extend the syntax
of function-names allows for current practice. Changing the name from
"function-specifier" to "function-name" avoids confusion and improves
consistency with the rest of the language, at the cost of a few small
changes to 88-002R.
Proposal (FUNCTION-NAME:MEDIUM):
Everything in FUNCTION-NAME:SMALL, and in addition:
Change the DEFUN macro to accept a function-name for its name argument,
instead of only accepting a symbol. If function-name is (SETF sym),
the body is surrounded by an implicit block named sym.
Rationale for FUNCTION-NAME:MEDIUM:
Keeping DEFUN consistent with DEFMETHOD is a good idea. Also 88-002R
says "The name of a generic function, like the name of an ordinary
function, can be either a symbol or a two-element list whose...", which
implies this change to DEFUN.
Proposal (FUNCTION-NAME:LARGE):
Everything in FUNCTION-NAME:MEDIUM, and in addition the following
numbered points, each of which could be adopted independently,
except where explicitly noted:
1. Change the function COMPILE to accept a function-name as its name
argument.
2. Change the function DISASSEMBLE to accept a function-name as its name
argument.
3. Change the FTYPE, INLINE, and NOTINLINE declarations and proclamations
to accept function-names, not just symbols, as function names.
4. Change the FLET and LABELS special forms to accept a function-name in
the name position, not just a symbol.
5. Change the TRACE and UNTRACE macros to accept function-names, not just
symbols, in the function name positions.
6. Change the ED function to accept (ED function-name) in place of
(ED symbol).
7. Change the syntax of a function call to allow a function-name as the
first element of the list, rather than allowing only a symbol.
8. Change the DEFMACRO macro and the MACROLET special form to accept a
function-name in the name position, not just a symbol. Change the
MACRO-FUNCTION function to accept function-names, not just symbols.
Change the last rule for SETF places to use
((SETF reader) #:temp-0 #:temp-1 #:temp-2...)
in place of
(FUNCALL (FUNCTION (SETF reader)) #:temp-0 #:temp-1 #:temp-2...)
so that (SETF reader) can be defined as a macro. This depends on item
7. If item 4 is rejected, MACROLET should be stricken from this item.
9. Add an optional environment argument to FDEFINITION, SETF of
FDEFINITION, FBOUNDP, and FMAKUNBOUND. This is the same as the
&environment argument to a macroexpander. This argument can be used to
access local function definitions, to access function definitions in the
compile-time remote environment, and to modify function definitions in
the compile-time remote environment.
10. Change the second, third, fourth, fifth, seventh, and ninth rules for
SETF places so that they only apply when the function-name refers to the
global function definition, rather than a locally defined function or
macro. (The ninth rule is the one that refers to DEFSETF and
DEFINE-SETF-METHOD; the other rules listed are the ones that list
specific built-in functions). The effect of this change is that SETF
methods defined for global functions are ignored when there is a local
function binding; instead, the function named (SETF reader), which may
have a local function binding, is called. This change is most useful
in connection with item 4, but does not actually depend on it.
11. Clarify that the eighth rule for SETF places (the one for macros)
uses MACROEXPAND-1, not MACROEXPAND.
Rationale for FUNCTION-NAME:LARGE:
This extends the new feature throughout the language, in order to make
things generally more consistent and powerful. Point by point:
1,2,3 - one should be able to compile, examine, and make declarations
about functions regardless of whether they are named with symbols or
with lists.
4 - locally defined non-generic SETF functions are a logical companion
to locally defined generic SETF functions, which can be defined with
GENERIC-FLET or GENERIC-LABELS. They make sense on their own, since one
might define a local reader function and want a local writer function
to go with it.
5,6 - one should be able to apply development tools to functions
regardless of how they are named. The function DOCUMENTATION was already
updated to work for function-names by 88-002R. There might be some
difficulty with implementation-dependent syntax extensions to TRACE and
UNTRACE conflicting with this new syntax.
7 - this restores consistency between the FUNCTION special form and the
first element of a function call form.
8 - it seems more consistent to allow macros to be named the same way
that ordinary functions are named. However, this might be considered
redundant with DEFSETF.
9 - this is not needed by the "chapter 1 and 2" level of CLOS, but might
be used by the metaobject based implementation of ENSURE-GENERIC-FUNCTION.
10 - this change was in SETF-FUNCTION-VS-MACRO and makes item 4 more useful.
11 - this change was in SETF-FUNCTION-VS-MACRO and is a good idea, but
actually is independent of everything else being proposed here.
Examples:
;This is an example of the sort of syntax 88-002R allows
(defmethod (setf child) (new-value (parent some-class))
(setf (slot-value 'child parent) new-value)
(update-dependencies parent)
new-value)
(setf (child foo) bar)
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this, if the MEDIUM or LARGE
;proposal is adopted.
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;The preceding example would have to be defined like this
;if only the SMALL proposal is adopted. This is a method
;all of whose parameter specializer names are T.
(defmethod (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when the earlier rules do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars
(cdr form)
(list new-value)
`(funcall #'(setf ,(car form)) ,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
Current practice:
No implementation supports exactly what is proposed. Symbolics Genera
and the TI Explorer support something close to the MEDIUM proposal, but
differing in a number of details. Symbolics Genera supports items 1, 2,
3, 6, and 11, and modified forms of items 5 and 8, of the LARGE proposal.
Moon considers this proposal's variations from Symbolics current practice
to be an improvement, although incompatible in some cases.
Many implementations currently support only symbols as function names.
Symbolics Genera and the TI Explorer have some additional function-name
syntaxes.
Cost to Implementors:
The SMALL and MEDIUM proposals are estimated to be no more than 50 lines
of code and require no changes to the "guts" of the interpreter and
compiler. Most of the code for this can be written portably and was
shown on two slides at the X3J13 meeting.
Some of the changes in the LARGE proposal are trivial, some require
the compiler to use EQUAL instead of EQ to compare function names, and
items 4, 7, and 8 might require a more substantial implementation
effort. Even that effort is estimated to be negligible compared to
the effort required to implement CLOS.
Cost to Users:
No cost to users, other than program-understanding programs, since this
is an upward compatible addition.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new feature,
but otherwise they will still work.
Cost of non-adoption:
We would have to make some other language change since the language
became inconsistent when 88-002R was adopted.
Performance impact:
This has no effect on performance of compiled code. It might slow
down the compiler and interpreter but not by very much.
Benefits:
CLOS will work as designed.
Esthetics:
Some people dislike using anything but symbols to name functions.
Other people would prefer that if the change is to be made at all,
the LARGE proposal be adopted so that the language is uniform in its
treatment of the new extended function names. Other proposals for
how to deal with SETF in CLOS were considerably less esthetic,
especially when package problems are taken into account.
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
Discussion:
Moon supports at least FUNCTION-NAME:MEDIUM. He does not necessarily
approve of all parts of FUNCTION-NAME:LARGE.
∂28-Jan-89 1011 CL-Cleanup-mailer Re: issue IN-PACKAGE-FUNCTIONALITY, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Jan 89 10:11:34 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA04670; Sat, 28 Jan 89 11:09:52 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA22944; Sat, 28 Jan 89 11:09:43 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901281809.AA22944@defun.utah.edu>
Date: Sat, 28 Jan 89 11:09:42 MST
Subject: Re: issue IN-PACKAGE-FUNCTIONALITY, version 5
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, masinter.pa@xerox.com,
cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 27 Jan 89 21:42 EST
A few comments on your amendment:
I am not sure why you think NIL must be treated specially, any more
than any other external symbol in the Lisp package.
I think the idea of trying to confine WITHIN-PACKAGE to being the
first form in the file is bogus, and the difficulty you have in
defining "first" is one reason why. Another thing is that the obvious
replacement for the "Put In Seven Extremely Randoms" convention is to
put a DEFPACKAGE at the top of the file, followed by a WITHIN-PACKAGE.
(I know that this convention is generally regarded as broken at least
in the case of multiple files in the same package, but many users have
tried to follow the recommendation given in CLtL, and this is a
reasonable thing to do if you've got a short module all in one file.)
The compile-time effects of WITHIN-PACKAGE can be well-defined
regardless of whether or not it appears first in the file, anyway.
Perhaps if I think about this a while longer I can come up with an
alternate specification that will still let you include the special case
for symbols accessible in *PACKAGE* and avoid the kind of problems I
mentioned in my previous message.
As to splitting this up as a separate issue, that might be a good idea
since it appears there will be at least two alternatives. I think
IN-PACKAGE-FUNCTIONALITY:NEW-MACRO ought to include the parts about
adding WITHIN-PACKAGE, removing IN-PACKAGE, and deleting the
troublesome paragraph in CLtL that implies COMPILE-FILE has to treat
the package functions specially (since the whole motivation for making
WITHIN-PACKAGE a macro is to avoid this requirement). I will start a
new compiler issue (called COMPILE-FILE-SYMBOL-HANDLING, unless I get
a better suggestion), that combines the parts from this issue and
issue CONSTANT-COMPILABLE-TYPES that deal with what package symbols end
up in. Sound OK?
-Sandra
-------
∂29-Jan-89 1325 Common-Lisp-Object-System-mailer Re: Issue: FUNCTION-NAME (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 29 Jan 89 13:24:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA22781; Sun, 29 Jan 89 14:23:25 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA23486; Sun, 29 Jan 89 14:22:46 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901292122.AA23486@defun.utah.edu>
Date: Sun, 29 Jan 89 14:22:45 MST
Subject: Re: Issue: FUNCTION-NAME (Version 1)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 27 Jan 89 22:48 EST
On the whole, I like this presentation much better than either of the
other two writeups that were circulated previously. I suspect that it
might be necessary to vote on each of the items in the LARGE proposal
individually, though. I think I would support items 1, 2, and 11, and
don't have any particular objections to 3, 5, and 6. For item 4, if
consistency with GENERIC-FLET and GENERIC-LABELS is an object, another
alternative is to change those two special forms to be like ordinary
FLET and LABELS, instead of vice versa.
-Sandra
-------
∂29-Jan-89 1428 CL-Cleanup-mailer Re: issue IN-PACKAGE-FUNCTIONALITY, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 29 Jan 89 14:28:40 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA23795; Sun, 29 Jan 89 15:27:08 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA23517; Sun, 29 Jan 89 15:27:00 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901292227.AA23517@defun.utah.edu>
Date: Sun, 29 Jan 89 15:26:58 MST
Subject: Re: issue IN-PACKAGE-FUNCTIONALITY, version 5
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
cl-cleanup@SAIL.STANFORD.EDU, cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 27 Jan 89 21:42 EST
Here is some wording that borrows from what you used, that says pretty
much what I intended to say in my original proposal.
When a compiled file is loaded, the interned symbols it references are
found by calling INTERN at load time with two arguments, the name of
the symbol and the package with the same name as the compile-time
symbol's home package. If no such package exists, an error is
signalled.
As far as I can make out, there are two situations where the two
proposals specify different behavior:
(1) The situation where there is a symbol accessible in the
compile-time value of *PACKAGE*, but with another home package. Your
proposal would have the loader INTERN the symbol in the load-time
value of *PACKAGE*, and mine would have it INTERN the symbol in its
compile-time home package. Unless there is an existing symbol with
the appropriate name that is accessible in both packages, the
load-time home package of the resulting symbol would differ under the
two proposals.
(2) The situation where a symbol is external at compile time, but
where there is no such external symbol at load time. Your proposal
would quietly INTERN it as internal symbol in *PACKAGE* if the symbol
were accessible in the compile-time *PACKAGE*, and otherwise signal an
error. Mine would always just quietly INTERN the symbol as internal
in its home package.
The more I think about this, the more I have come to believe that no
conforming program ought to cause either of these two situations to
arise, and that we could just leave the behavior unspecified in these
cases. It's a user interface issue, much like what happens when you
incompatibly redefine a DEFSTRUCT. Or, to give a stronger parallel,
it's like what happens when you load a file that was compiled with
some DEFSTRUCT definitions that are incompatible with the DEFSTRUCT
definitions that happen to be around at load time. (Proposal
COMPILE-ENVIRONMENT-CONSISTENCY says that the behavior is unspecified
in that situation.)
As I understand it, one rationale for the proposal you suggest is that
it makes LOADing compiled files more like LOADing source files, in that
symbols that would be interned in *PACKAGE* when the source file is
loaded ought to also be interned in *PACKAGE* when the compiled file
is loaded, regardless of what the compile-time value of *PACKAGE* was.
Here is an example to explain why I believe that the compile-time
value of *PACKAGE* -does- matter. PCLS has two different packages,
the PSL package and the LISP package, which do not use each other.
Many functions, macros, and special forms with the same names exist in
both packages as distinct symbols with different definitions. If I
have a file that really wants to use the Common Lisp definitions,
rather than the PSL definitions, the symbols from LISP package -must-
be accessible at compile time in order for the compiler to apply the
right set of macro expansions and use the right set of special form
compilers. If the compile-time *PACKAGE* is such that the PSL package
macros get used instead, then the compiled file would end up
referencing functions that don't even exist in the LISP package, and
under your proposal you'd lose no matter what the load-time value of
*PACKAGE* is. This is why PCLS ended up including an explicit package
prefix on all symbols in compiled files. The same considerations
apply equally well when talking about user-defined macros and all the
other kinds of things that the compiler is allowed to "wire in" to the
code it compiles.
Basically, what I would like to do is come up with a unified proposal
that is compatible with both of the existing ones where they agree,
and leave what happens in the situations where they disagree to be
explicitly vague. In other words, it would place some additional
COMPILE-FILE/LOAD consistency requirements on conforming programs --
something along the lines of saying that the compile-time value of
*PACKAGE* must be the same as the load-time value, any symbols
referenced in the compiled file that are accessible in *PACKAGE* but
with another home package at compile-time must also be accessible in
both packages at load-time, etc. (I'll obviously have to think about
this some more to get all the details right.)
Do you approve of this general direction?
-Sandra
-------
∂30-Jan-89 0653 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Jan 89 06:53:50 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 529852; Mon 30-Jan-89 09:51:26 EST
Date: Mon, 30 Jan 89 09:51 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFMACRO-LAMBDA-LIST (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890130095112.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Sigh, the DESTRUCTURING-BIND discussion made it clear that it's time to
deal with a couple of details about DEFMACRO which have been left vague...
-----
Issue: DEFMACRO-LAMBDA-LIST
Forum: Cleanup
References: 8.1 Macro Definition (CLtL pp144-151),
Issue DESTRUCTURING-BIND
Category: CLARIFICATION/CHANGE
Edit history: 30-Jan-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The description of the DEFMACRO lambda list currently contains some
mis-statements and leaves some ambiguities:
1. Can &BODY, &WHOLE, and &ENVIRONMENT appear at recursive levels of the
DEFMACRO lambda list?
The description of &WHOLE (p145) specifies that &WHOLE must occur ``first
in the lambda list,'' but the description of a lambda list says that
``a lambda may [recursively] appear in place of the parameter name.''
Consequently, the question arises whether &WHOLE should be permitted to
be a synonym for &REST at inner levels of a DEFMACRO lambda list.
The descriptions of &BODY and &ENVIRONMENT do not contain syntactic
restrictions on where they may appear.
2. Does using &WHOLE affect the pattern of arguments permitted by DEFMACRO.
Proposal (DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION):
1. a. Specify that &BODY may appear at any level of a DEFMACRO lambda list.
b. Specify that &WHOLE may only appear at the top level of a DEFMACRO
lambda list.
c. Specify that &ENVIRONMENT may only appear at the top level of a
DEFMACRO lambda list.
2. Clarify that using &WHOLE does not affect the pattern of arguments
specified by DEFMACRO.
Examples:
1. (DEFMACRO DM1A (&WHOLE FORM A B) ...) is defined.
(DEFMACRO DM1B (A (&WHOLE B C) D) ...) is undefined.
(DEFMACRO DM1C (A B &ENVIRONMENT ENV) ...) is defined.
(DEFMACRO DM1D (A (B &ENVIRONMENT ENV) C) ...) is undefined.
(DEFMACRO DM1E (A B &BODY X) ...) is defined.
(DEFMACRO DM1F (A (B &BODY X) C) ...) is defined.
2. (DEFMACRO DM2A (&WHOLE X) `',X)
(MACROEXPAND '(DM2A)) => (QUOTE (DM2A))
(MACROEXPAND '(DM2A A)) is an error.
(DEFMACRO DM2B (&WHOLE X A &OPTIONAL B) `'(,X ,A ,B))
(MACROEXPAND '(DM2B)) is an error.
(MACROEXPAND '(DM2B Q)) => (QUOTE ((DM2B Q) Q NIL))
(MACROEXPAND '(DM2B Q R)) => (QUOTE ((DM2B Q R) Q R))
(MACROEXPAND '(DM2B Q R S)) is an error.
Rationale:
1. a. An example on p151 makes it clear that this was the intent.
b. At top level, &WHOLE and &REST do something different, so two
keywords are warranted. Embedded, there is only a need for &REST.
Providing &WHOLE would just encourage confusion among novices.
This simplifies the implementation of DEFMACRO if we introduce a
DESTRUCTURING-BIND which does not understand &ENVIRONMENT.
This also reduces the temptation for novices to confuse &WHOLE
with &REST.
c. The environment is never different at top level than embedded.
Permitting &ENVIRONMENT to occur embedded would only encourage
the misconception that there was a potential difference.
This simplifies the implementation of DEFMACRO if we introduce a
DESTRUCTURING-BIND which does not understand &ENVIRONMENT.
2. This allows useful syntax checking.
One can always trivially write
(DEFMACRO ... (&WHOLE FORM &REST IGNORE) ...)
to get around the error checking this forces.
Current Practice:
1. a. Symbolics Genera permits &BODY at any level. This is compatible.
b. Symbolics Genera seems to permit &WHOLE at any level. When embedded,
it is treated as a synonym for &REST. Since the proposal is to make
this situation is undefined, this is technically compatible.
c. Symbolics Genera does not permit &ENVIRONMENT except at top level.
This is compatible.
2. Symbolics Genera has this behavior when &WHOLE appears at top level,
but not at recursive levels (where &WHOLE is treated as a synonym for
&REST). Since this proposal also outlaws &WHOLE at recursive levels,
it is technically compatible.
Cost to Implementors:
None. This change is upward compatible.
Note in particular that implementations which currently do not error check
the pattern when &WHOLE is used are technically compatible, since that
situation is made "undefined" by this proposal. This basically just
restricts the set of things users can do in portable code.
Cost to Users:
Very slight. Probably most users don't do any of the things this proposal
addresses. If they do, most cases can probably trivially be found and fixed
by very superficial editing. In any case, any code which touches on these
areas is probably already not portable.
Cost of Non-Adoption:
Some fuzzy places in DEFMACRO continue to exist.
It's harder to introduce DESTRUCTURING-BIND because describing its relation
to DEFMACRO is difficult.
Benefits:
The language is a little tighter.
Aesthetics:
Negligible impact.
Discussion:
Part 2 of this issue came up during the discussion of DOTTED-MACRO-FORMS
but was not pursued until now.
Pitman supports these clarifications.
∂30-Jan-89 0704 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Jan 89 07:03:59 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 529856; Mon 30-Jan-89 10:01:57 EST
Date: Mon, 30 Jan 89 10:01 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND (Version 2)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19890128020158.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890130100149.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 27 Jan 89 21:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I support version 2 of this. I have a couple of minor comments:
DESTRUCTURING-BIND should not allow &WHOLE any more than it should allow
&ENVIRONMENT. Those two features are specific to macroexpanders.
Sigh. EB sent something which touched on this same issue. I guess you're
right, but I think before we disallow them, we should probably make it
clear that &WHOLE and &ENVIRONMENT only belong at toplevel of a DEFMACRO
lambda list and not within. That would make the implementation-strategy
for DEFMACRO more apparent. I made a separate issue,
DEFMACRO-LAMBDA-LIST, to discuss this.
Actually, it seems to me that the same case could be made for &BODY. It
has no purpose in DESTRUCTURING-BIND since an explicit call to
DESTRUCTURING-BIND will never have to affect the way something pretty
prints. Nevertheless, since it is useful to have &BODY appear at recursive
levels of DEFMACRO binding forms, I think it should be permitted here.
Still, we should be up front about our motivations here.
Both LOOP and DESTRUCTURING-BIND allow NIL in place of a variable
name as a way of ignoring a portion of the destructured tree, in
Symbolics current practice. I think that's a good idea and should
go in the standard. It's only an abbreviation for a dummy variable
and a DECLARE IGNORE, but the whole destructuring feature is nothing
but an abbreviation anyway.
This is ok with me. Does anyone object? If I hear no objection, this
change will be in the next version. Especially in error-checking versions
where you might otherwise appear to be matching an empty list by the
normal destructuring rules (signalling an error in some implementations)
this might be important.
Of course, there are other places where such a convention would be
useful, too. LAMBDA, MULTIPLE-VALUE-BIND and MULTIPLE-VALUE-SETQ come
immediately to mind. But I guess it's really too late to consider
ammending those. Oh well...
∂30-Jan-89 0720 CL-Cleanup-mailer Issue: FUNCTION-NAME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Jan 89 07:20:34 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 529874; Mon 30-Jan-89 10:18:34 EST
Date: Mon, 30 Jan 89 10:18 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-NAME (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU,
Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <19890128034814.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890130101826.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
I'm still thinking about this, but while I am I wanted point out that
MEDIUM is unacceptable to me because I don't think FLET and DEFUN should
disagree on what they permit as defined names. If FLET were added to
MEDIUM, I suspect I'd think it was an internally consistent position.
LARGE has an appeal to me in general, but I'm still mulling over
the specifics.
I'll reply in more detail later.
∂30-Jan-89 0903 CL-Cleanup-mailer Issue: LISP-PACKAGE-NAME, (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Jan 89 09:02:59 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 529971; Mon 30-Jan-89 12:00:57 EST
Date: Mon, 30 Jan 89 12:00 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-PACKAGE-NAME, (Version 1)
To: alarson@src.honeywell.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8901280201.AA03960@pavo.src.honeywell.com>
Message-ID: <890130120046.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 27 Jan 89 20:01:47 CST
From: alarson@src.honeywell.com (Aaron Larson)
I have two comments with regard to this proposal;
first, it should mention the user package (perhaps cl-user),
You're a little vague. I guess you mean it should say that the USER package
is called CL-USER and not USER.
I guess I think this is probably the right thing, since there is a contract
already in CLtL that USER should use LISP, and compatibility would be best
be maintained by making CL-USER, which must use CL, be different.
(None of this is compatible for Symbolics systems, of course, since CL is
already a nickname for LISP, and CL-USER is already a nickname for USER.
But personally think that's a problem we can ultimately dig our way out of.)
secondly there is a much simpler way to get print/read inconsistency than
that described in the proposal, just have *PACKAGE* bound to a package
that does not use CL be current when printing.
I agree this is an issue, and should be documented, although in spite of its
simplicity, again I don't think it's a common event. The only time I've ever
done it has been in routines where I wanted to expose the home package. If
we document that the home package is not something you depend on, then portable
programs will not try to expose the home package, so I think the situation
will continue to be quite rare.
I would feel better requiring CL:SYMBOL-PACKAGE returning the CL package
for symbols defined in the spec.
The problem here is that CL:SYMBOL-PACKAGE may fail to be predictive of what
the printer will do. Supposing that you have a symbol SI:NIL which must be
the false value for Zetalisp, CLtL, and ANSI Common Lisp. If
(ZL:SYMBOL-PACKAGE 'SI:NIL) must return #<Package ZETALISP>
(LISP:SYMBOL-PACKAGE 'SI:NIL) must return #<Package LISP>
(CL:SYMBOL-PACKAGE 'SI:NIL) must return #<Package COMMON-LISP>
then how will the symbol print? That is, what if I do (ZL:PRINT 'LISP:NIL)
or (LISP:PRINT 'CL:NIL)? It looks to me like the possibilities are:
1. You must never share code between lisp dialects.
This would be very sad. Important things can come from an ability to
co-exist, and it's very easy to accidentally constrain things so that
co-existing dialects only really work if you violate one or the other's
spec.
2. You should assume that ZL:PRINT will somehow pass information through
to the symbol printer to say to print ZL:NIL and not CL:NIL or LISP:NIL.
Analogously for CL:PRINT, etc.. Analogously for CL:SYMBOL-PACKAGE, etc.
This would make CL:SYMBOL-PACKAGE and CL:PRINT internally consistent,
at the cost of slowing down PRINT and SYMBOL-PACKAGE.
3. You should assume that ZL:PRINT, CL:PRINT, and LISP:PRINT are really
the same function, and that ZL:SYMBOL-PACKAGE, CL:SYMBOL-PACKAGE, and
LISP:SYMBOL-PACKAGE are really the same function, and that some magic
undocumented internal dynamic switch controls what `language' you are
really in at any given time. This addresses the question of whether
(CL:DEFUN LISP:IDENTITY (ZL:X) ZL:X)
is a CLtL, Zetalisp, or Ansi Common Lisp program by defining that the
answer is context-dependent. Also, this is less complicated than explicit
data flow and still achieves internal consistency, but the dynamic
nature of the switch makes programs hard to prove correct. Binding the
`current language' might affect things you didn't intend to affect, as
is always the problem with dynamic switches.
4. You should assume the home package for initial symbols in package
COMMON-LISP is not reliable, and assure that the binding of *PACKAGE* is
appropriate if you plan to do code interchange between implementations.
For example, (LET ((*PACKAGE* (FIND-PACKAGE "COMMON-LISP"))) (PRINT ...))
will do exactly the right thing for code interchange.
I've oversimplified a bunch of things here, but I hope you can get the
basic idea from this presentation. As you can probably see, only option 4
seems suitably efficient to me, which is why I proposed it.
Keep in mind, too, that in these options we're really only free to
change what ANSI CL does. What Zetalisp and CLtL (and perhaps other
dialects to come, such as ISO) say really must be just taken as fixed.
I have to emphasize that I don't make this recommendation lightly. I
have worked for many years in the Symbolics environment, which must deal
usefully with Zetalisp and Common Lisp in the same environment. Also, my
Last two years I have been intensely involved in the design of Cloe, a
third implementation of Lisp which co-exists in the same environment under
a completely different set of restrictions than the other two.
In my work with Cloe, I initially tried to make SYMBOL-PACKAGE do as
you suggest and I found it leads to a house of cards which is doomed
to eventually topple. My suggestions about what to leave undefined are
motivated out of practical respect for the number of legitimate concerns
on all sides.
Moral: Better for programmers to understand that there are things on
which they cannot rely and against which they must program defensively
than for them to believe there are things upon which they can rely and
to have that belief turn out to have been a mirage.
∂30-Jan-89 0910 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Jan 89 09:10:46 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 529981; Mon 30-Jan-89 12:07:19 EST
Date: Mon, 30 Jan 89 12:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue IN-PACKAGE-FUNCTIONALITY, version 5
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: sandra%defun@cs.utah.edu, masinter.pa@xerox.com,
cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19890128024204.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890130120708.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
I happen not to like the name WITHIN-PACKAGE.
All of the other package operations are verbs. USE-xxx, MAKE-xxx,
EXPORT-xxx, etc. IN-PACKAGE has always been a glaring exception,
perhaps deliberately due to its dual role, perhaps due to oversight.
Anyway, I would just as soon see this use a verb, too.
Also, if IN-PACKAGE is retained for compatibility, I predict that
people will confuse it with WITHIN-PACKAGE often enough to be
an annoyance. I think that if we can conveniently avoid that
gratuitous confusion, we should do so.
I suggest the name SELECT-PACKAGE.
∂30-Jan-89 0915 CL-Cleanup-mailer Re: issue IN-PACKAGE-FUNCTIONALITY, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Jan 89 09:15:02 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA10192; Mon, 30 Jan 89 10:11:52 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA25499; Mon, 30 Jan 89 10:11:37 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901301711.AA25499@defun.utah.edu>
Date: Mon, 30 Jan 89 10:11:36 MST
Subject: Re: issue IN-PACKAGE-FUNCTIONALITY, version 5
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
masinter.pa@xerox.com, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 30 Jan 89 12:07 EST
SELECT-PACKAGE is fine with me. I was never very happy with
WITHIN-PACKAGE myself, but it was the best I could come up with (and I
didn't get any better suggestions the last time I asked).
-Sandra
-------
∂30-Jan-89 0917 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Jan 89 09:17:06 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 529993; Mon 30-Jan-89 12:15:06 EST
Date: Mon, 30 Jan 89 12:14 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
References: <8901272310.AA10127@void.ai.mit.edu>,
<8901282129.AA10496@void.ai.mit.edu>
Message-ID: <890130121458.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
The following endorsement came privately from Jonathan..
Date: Sat, 28 Jan 89 16:29:16 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
CONDITION-RESTARTS:PERMIT-ASSOCIATION looks fine to me.
It would certainly clean things up in some code I'm working on
∂30-Jan-89 1003 Common-Lisp-Object-System-mailer Issue: FUNCTION-NAME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Jan 89 10:03:07 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 JAN 89 10:00:38 PST
Date: Mon, 30 Jan 89 10:00 PST
From: Gregor.pa@Xerox.COM
Subject: Issue: FUNCTION-NAME (Version 1)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU,
Common-Lisp-Object-System@SAIL.STANFORD.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <19890128034814.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890130180031.2.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
I support FUNCTION-NAME:MEDIUM and may support LARGE once I think about
it some more.
As I explained in Hawaii, support for either of these is based on the
:conc-name bugs being removed from the condition system. Of course, I
believe the best way to do that is to CLOSify it.
-------
∂30-Jan-89 1458 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Jan 89 14:58:31 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 JAN 89 14:49:05 PST
Date: 30 Jan 89 14:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 30 Jan 89 17:35 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: rpg@lucid.com, Moon@STONY-BROOK.SCRC.Symbolics.COM, dussud@lucid.com,
JonL@lucid.com, Masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <890130-144905-6017@Xerox>
I'd just as soon that technical discussions about cleanup proposals happen
on the cl-cleanup distribution list.
As long as we're quibbling about wording, we might as well get wording that
we like. If we're not already quibbling about wording, then we can put it
off for cl-editorial to do.
I'd rather proposals be explicit about the cases and cut things down later.
We do best if we describe the input/output behavior of functions with a
case analysis, where it is clear that all of the cases are covered. In a
cleanup proposal, you can omit repeating CLtL by saying "as described in
CLtL", or, if necessary for clarity (e.g., when there is some evidence that
CLtL's reading has been misread or not read), to repeat CLtL or rephrase it
with a "Clarify".
∂30-Jan-89 1826 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Jan 89 18:26:34 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA07555; Mon, 30 Jan 89 19:24:53 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA25846; Mon, 30 Jan 89 19:24:50 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901310224.AA25846@defun.utah.edu>
Date: Mon, 30 Jan 89 19:24:48 MST
Subject: issue IN-PACKAGE-FUNCTIONALITY, version 6
To: cl-cleanup@sail.stanford.edu
Cc: cl-compiler@sail.stanford.edu
Here is a new version of the writeup on this issue which incorporates
all of the suggestions I've received so far. In particular, all of the
parts dealing with compile/load package consistency requirements have
been split off to a new cl-compiler issue, COMPILE-FILE-SYMBOL-HANDLING
(I'm working on a draft writeup). And, the name of the macro has been
changed to SELECT-PACKAGE.
Issue: IN-PACKAGE-FUNCTIONALITY
References: IN-PACKAGE (p182-183)
Category: CHANGE
Edit history: 07-Jul-88, Version 1 by Pitman
7-Oct-88, Version 2 by Masinter (discussion)
8-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter
20-Jan-89, Version 5 by Loosemore
30-Jan-89, Version 6 by Loosemore
Related-Issues: DEFPACKAGE (passed)
COMPILE-FILE-SYMBOL-HANDLING
Problem Description:
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
A more general problem is that the "Put In Seven Extremely Randoms"
convention described in CLtL is now recognized by many people as being
unsatisfactory for both package definition and package selection.
The DEFPACKAGE macro provides a much cleaner mechanism for package
definition, but there is still a need for a convenient way to select
a package that has well-defined compilation semantics.
Proposal (IN-PACKAGE-FUNCTIONALITY:NEW-MACRO):
Add a new macro:
SELECT-PACKAGE name [macro]
This macro causes *PACKAGE* to be set to the package named NAME,
which must be a symbol or string. An error is signalled if the
package does not already exist. Everything this macro does is also
performed at compile time if the call appears at top-level.
Remove the function IN-PACKAGE from the standard.
Remove the second paragraph of section 11.7 in CLtL. (This includes
the requirement for special compile-time treatment of the various
package functions.)
Rationale:
This could allow improved error checking and modularity, with only
minimal loss of functionality.
The rationale for proposing SELECT-PACKAGE as a replacement for
IN-PACKAGE, rather than simply changing IN-PACKAGE to have this
behavior, is that such an incompatible change would be confusing to
many people, and would make it more difficult to detect obsolete
usages. There is nothing in this proposal that would prevent
implementations from continuing to provide IN-PACKAGE as an extension.
Making SELECT-PACKAGE a macro rather than a function means that there
is no need to require COMPILE-FILE to handle it specially. Since
DEFPACKAGE is also defined to side-effect the compilation environment,
there is no need to require any of the package functions to be treated
specially by the compiler.
The language in section 11.7 of CLtL puts the burden on
implementations of ensuring that all symbols in a file which is
compiled and loaded end up in the same package that they would if the
source file were loaded interpretively. No implementation can
possibly meet this requirement because, in general, the runtime
behavior of the program cannot be predicted by the compiler.
Current Practice:
Probably no one implements this behavior exactly since it's an
incompatible change to CLtL.
Cost to Implementors:
The SELECT-PACKAGE macro can be implemented trivially by using
EVAL-WHEN in its expansion:
(defmacro within-package (name)
`(eval-when (eval compile load)
(setq *package*
(or (find-package ',name)
(error "Package ~s does not exist." ',name)))))
The changes required to COMPILE-FILE to remove the magic treatment
of the package functions are also likely to be small.
Cost to Users:
In most cases, minor syntactic changes to some files would be
necessary. Programmers that are now using the "Put In Seven
Extremely Randoms" convention will probably find it straightforward
to convert their code to do a DEFPACKAGE followed by a
SELECT-PACKAGE.
Cost of Non-Adoption:
The specification of COMPILE-FILE will be much more difficult to
understand.
The standard will require compilers to solve the halting problem.
Benefits:
Modular package declarations would be encouraged and errors due
to demand-creation of packages would be easier to detect.
The specification of COMPILE-FILE will be simplified.
There will be a clear statement of the requirements for program
conformance, as relating to usage of packages.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether
the package should exist already or not) is clearly not aesthetic.
Removing it can't be any worse.
The fact that the currently stated requirements for handling of
the package functions by the compiler are not implementable is
clearly not aesthetic.
Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):
Eliminate the ability of IN-PACKAGE to create a package on demand.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
The results of calling IN-PACKAGE if the package does not already
exist are implementation dependent; implementations "should signal"
an error, or otherwise provide the user with a way to recover from
the situation.
Examples:
#1: (IN-PACKAGE 'NO-SUCH-PACKAGE) ;would signal an error
#2: (DEFPACKAGE FOO ...options...) ;defines/creates a package
(IN-PACKAGE 'FOO) ;selects an existing package
Rationale:
This could allow improved error checking and modularity, with only
minimal loss of functionality.
Current Practice:
Probably no one implements this behavior since it's in direct
contradiction of both the definitions and numerous examples in CLtL.
Cost to Implementors:
As written, no change to implementations is required, but many will
want to make IN-PACKAGE signal an error. This change would be
straightforward to implement. The cost may not be trivial in all
cases, but should not be very large.
Cost to Users:
In most cases, minor syntactic changes to some files would be
necessary.
In some cases, no changes would be necessary since files may
already be doing IN-PACKAGE in situations where the author is
hoping he's made sure the real package declaration is already
loaded.
Cost of Non-Adoption:
Reduced error checking.
Less modular code.
Benefits:
Errors due to demand-creation of a package by IN-PACKAGE without
appropriate uses of the :USE or :NICKNAMES or without appropriate
calls to EXPORT, etc. afterward would be easier to detect.
Modular package declarations would be encouraged.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether
the package should exist already or not) is clearly not aesthetic.
Some people feel this change would be an aesthetic improvement.
Others feel that an incompatible change to IN-PACKAGE would merely
be confusing.
Discussion:
The dual use of IN-PACKAGE has not been helpful and is confusing.
Both proposals represent an incompatible change to the language as
described in CLtL and will break any program that uses the "Put In
Seven Extremely Randoms" convention described in section 11.9.
Some people may find proposal NEW-MACRO more palatable if it merely
deprecated IN-PACKAGE, instead of removing it entirely.
Loosemore and Moon support proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO.
-------
∂31-Jan-89 0233 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 31 Jan 89 02:33:08 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03991g; Tue, 31 Jan 89 02:27:38 PST
Received: by bhopal id AA14720g; Tue, 31 Jan 89 02:29:58 PST
Date: Tue, 31 Jan 89 02:29:58 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901311029.AA14720@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: Kent M Pitman's message of Mon, 30 Jan 89 10:01 EST <890130100149.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND (Version 2)
re: [use of NIL as an implicitly ignored variable, in binding constructs]
Of course, there are other places where such a convention would be
useful, too. LAMBDA, MULTIPLE-VALUE-BIND and MULTIPLE-VALUE-SETQ come
immediately to mind. But I guess it's really too late to consider
ammending those. Oh well...
You might not remember that VAX/NIL had regular destructuring as a standard
feature of LET and DEFUN, along with the ignore-NIL hack. The one place
that it didn't easily generalize was for SETQ -- thus VAX/NIL had a
special-form/macro called DESETQ, as a destructuring version of SETQ.
As I remember it, some folks objected to the destructuring capability
for LET based on what they thought ought to be "primitive"; and others
objected to it in DEFUN for similar reasons. Of course, from an
implementational point of view, neither LET nor DEFUN is typically
primitive; they are simply the portable interface to a useful construct.
But the final killer for these extensions were what you term the
"religious wars" regarding how to specify destructuring over a list:
(destructuring-bind (a b c) (produce-a-list) ...)
or
(destructuring-bind `(,a ,b ,c) (produce-a-list) ...)
VAX/NIL actually used an extended form like:
(destructuring-bind #(a b c) (produce-a-vector) ...)
and *almost* had another extension like:
(destructuring-bind #S(FOO a b c) (produce-a-struct-FOO) ...)
Neither extension was extensible in the more general sense, but they
were certainly useful in writing a peephole optimizer for the output
a NIL compiler.
Incidentally, the place where LOOP and your recent proposal might
"share" is if there were a destructuring version of SETQ. It's
unlikely, however, that as many implementations provide the
equivalent of DESETQ as provide DESTRUCTURING-BIND. Again, I
might mention that I feel there is a low-level primitive that
would facilitate writing all these "destructuring" forms --
for LOOP, for DESTRUCTURING-BIND, for DESETQ, etc -- but it may
not be worth it to try to "kernelize" this idea.
-- JonL --
∂01-Feb-89 1140 CL-Cleanup-mailer Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Feb 89 11:40:03 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 531729; Wed 1-Feb-89 14:38:03 EST
Date: Wed, 1 Feb 89 14:37 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890201143749.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: SETF-OPTIONAL-ARGUMENTS
Forum: Cleanup
References: SETF (CLtL pp94-97)
Category: CLARIFICATION/CHANGE
Edit history: 01-Feb-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The description of SETF is silent on the question of how to treat
place forms for functions which permit optional arguments. For
example, it says that you can SETF a GETHASH expression, but it
doesn't say what that means when the optional argument is provided.
A consequence of any outcome of this clarification should be to
advise users about how they should write SETF methods of their own,
since enforcing any chosen protocol requires programmer cooperation.
Test Case:
(DEFVAR *HT* (MAKE-HASH-TABLE)) ;Line 1
(GETHASH 'A *HT*) => NIL, NIL, NIL ;Line 2
(SETF (GETHASH 'A *HT* 0) 0) => 0 ;Line 3
(GETHASH 'A *HT* 0) => 0, T, A ;Line 4
(GETHASH 'A *HT*) => ?? ;Line 5
Proposal (SETF-OPTIONAL-ARGUMENTS:DISALLOW-OPTIONALS):
Define that when SETF is called on a place which permits optionals,
it is an error to specify the optionals.
This makes line 3 of the test case have "undefined consequences".
Proposal (SETF-OPTIONAL-ARGUMENTS:IGNORE-OPTIONALS):
Define that when SETF is called on a place which permits optionals,
the optional arguments are ignored.
This makes the result on line 5 of the test case be 0, T, A.
Proposal (SETF-OPTIONAL-ARGUMENTS:INVERT-EXACTLY):
Define that when SETF is called on a place which permits optionals,
only the effect of that particular pattern of optionals needs be updated.
This makes the result on line 5 of the test case be NIL, NIL, NIL.
Proposal (SETF-OPTIONAL-ARGUMENTS:EXPLICITLY-VAGUE):
Define that when SETF is called on a place which permits optionals,
the implementation is free to either ignore the optional arguments
or to exactly invert the expression.
This makes the result on line 5 of the test case be either
NIL, NIL, NIL or 0, T, A.
Rationale:
For that programmers of portable code will know what to expect,
implementations should either explicitly agree on this, or they
should explicitly agree to disagree...
DISALLOW-OPTIONALS avoids what some might see as a questionable
situation.
IGNORE-OPTIONALS makes the behavior of later accesses without the
optional more reliable in some cases. It also eliminates the need
to guard against an optional creeping in when a macro is
constructing a SETF form from other code.
INVERT-EXACTLY permits the implementation to optimize storage usage
in some cases. It also gives what some feel is a cleaner `conceptual'
description of the overall intent of SETF.
EXPLICITLY-VAGUE is a fall-back in case of committee deadlock.
Current Practice:
Symbolics Genera and Symbolics Cloe implement IGNORE-OPTIONALS.
Cost to Implementors:
Numerous highly localized changes.
If a particular implementation has documented its behavior on this point
and is forced to change, some documentation impact might occur.
Cost to Users:
The situation is currently vague enough that correct code should probably
not be relying on the behavior in question. However, in practice, some
implementation-specific code could be broken, depending on the outcome.
Cost of Non-Adoption:
A gratuitously vague specification.
Benefits:
Defining this clearly would allow both for portable programs to know
what to expect, and some of the possible options would increase the
space of possible constructs available for use.
Aesthetics:
Each proposal has an angle on aesthetic appeal which is closely coupled
with the rationale for choosing it.
Discussion:
Pitman's feelings on this will differ depending on what turns out to
be current practice. His preference leans toward IGNORE-OPTIONALS because
he guesses that's current practice in most implementations, and hence
offers greatest linguistic stability. If it turns out that implementations
vary widely in current practice, though, his preference might lean more
toward INVERT-EXACTLY due to aesthetic appeal.
∂01-Feb-89 1206 CL-Cleanup-mailer Re: Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Feb 89 12:06:02 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 FEB 89 11:50:27 PST
Date: 1 Feb 89 11:48 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 1 Feb 89 14:37 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890201-115027-10967@Xerox>
??? GETHASH returns two values, yet your examples has it returning 3.
I'm baffled by this issue, however. "SETF may be used with GETHASH to make
new entries in a hash table. ... The default argument may be specified to
GETHASH in this context; it is ignored by SETF, but may be useful in such
macros as INCF that are related to SETF."
This seems perfectly clear to me. I don't think that this is a SETF policy
at all. I think you should withdraw this.
∂01-Feb-89 1208 CL-Cleanup-mailer Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Feb 89 12:08:24 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 531777; Wed 1-Feb-89 15:06:26 EST
Date: Wed, 1 Feb 89 15:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890201143749.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890201150608.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Someone here just pointed me at p165 for GET and p167 for GETF.
Also, it came up that the 2nd to nth return value in my test
case were wrong, making this a non-issue for GETHASH, since
the found-p information reveals whether you've cheated.
Nevertheless, the issue remains for user-defined functions
and we should probably offer general advice with SETF rather
than point by point advice on consumers like GET and GETF,
so that users will know what the general rule is.
∂01-Feb-89 1224 CL-Cleanup-mailer Re: Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Feb 89 12:24:05 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 531794; Wed 1-Feb-89 15:21:34 EST
Date: Wed, 1 Feb 89 15:21 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890201-115027-10967@Xerox>
Message-ID: <890201152120.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 1 Feb 89 11:48 PST
From: masinter.pa@Xerox.COM
??? GETHASH returns two values, yet your examples has it returning 3.
Sorry. That was a Genera extension creeping in. Normally Cloe protects
me from such things, but I guess I missed that one.
I'm baffled by this issue, however. "SETF may be used with GETHASH to make
new entries in a hash table. ... The default argument may be specified to
GETHASH in this context; it is ignored by SETF, but may be useful in such
macros as INCF that are related to SETF."
I have to say that this case-by-case treatment upsets my sensibilities.
For example, consider SUBSEQ. Its treatment of optionals is not spelled out
in its description, but is apparently spelled out in the description of
DEFSETF.
However, as you observe, it is apparently the status quo, and it's late
in the cycle, so...
This seems perfectly clear to me. I don't think that this is a SETF policy
at all. I think you should withdraw this.
Would anyone object if I instructed Kathy to make the following changes in
presentation:
- For GET, GETF, and GETHASH (and any others where it occurs), change
"ignored by SETF" to "ignored by the SETF expander function for <fn>".
- In the description of SETF, add wording saying:
Some place forms involve uses of accessors which take optional arguments.
Whether those optional arguments are permitted by SETF, or what their use
will be, is up to the SETF expander function and is not under the control
of SETF. The documentation for any function which accepts optional, rest,
or keyword arguments and which claims to be usable with SETF must specify
how those arguments will be treated.
∂01-Feb-89 2123 CL-Cleanup-mailer New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Feb 89 21:23:19 PST
Return-Path: <gls@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 2 Feb 89 00:13:00 EST
Received: by sauron.think.com; Thu, 2 Feb 89 00:19:06 EST
Date: Thu, 2 Feb 89 00:19:06 EST
From: gls@Think.COM
Message-Id: <8902020519.AA03069@sauron.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN
References: ADJUST-ARRAY (p297)
MAKE-ARRAY (pp286-289)
ADJUSTABLE-ARRAY-P (p293)
ADJUST-ARRAY-NOT-ADJUSTABLE
Category: CLARIFICATION/CHANGE
Edit history: 02-Feb-89, Version 1 by Steele
Problem description:
The vote at the January 1989 meeting on ADJUST-ARRAY-NOT-ADJUSTABLE
left the language in an inconsistent state. It also left
ADJUSTABLE-ARRAY-P with a fairly useless definition.
The amendment presented and approved at the January meeting stated:
(1) The results are undefined if ADJUST-ARRAY is invoked on an array
that was created by MAKE-ARRAY without supplying :ADJUSTABLE <non-nil>.
(2) ADJUSTABLE-ARRAY-P returns true of an array created using
:ADJUSTABLE <non-nil>.
(3) If ADJUST-ARRAY is invoked on an array for which ADJUSTABLE-ARRAY-P
returns false, an error is signalled.
The inconsistency is that the amendment failed to strike these
parts of the original proposal:
Clarify that the implication of [the first three paragraphs of the
original proposal] is that saying that an array A "is adjustable"
means that (ADJUSTABLE-ARRAY-P A) => true. ...
Clarify that this legitimizes ADJUSTABLE-ARRAY-P as an appropriate
predicate to determine whether ADJUST-ARRAY will reliably succeed.
The latter is in conflict with the amendment, for ADJUSTABLE-ARRAY-P
being true is no longer a guarantee that ADJUST-ARRAY can succeed. The
best that can be said is that if ADJUSTABLE-ARRAY-P is false then
ADJUST-ARRAY is guaranteed to signal an error. (Some implementations
might provide the extension that ADJUSTABLE-ARRAY-P being true guarantees
that ADJUST-ARRAY will win.) Therefore the former is also nonsensical,
because it is silly to say that an array is adjustable if in fact an
adjustable array (one for which ADJUSTABLE-ARRAY-P is true) cannot be
adjusted by ADJUST-ARRAY.
Another point is that some persons have been concerned about the language
being in a state where one cannot guarantee that MAKE-ARRAY will create a
simple array. The concerns surround the question of a portable way to
make declarations about arrays that can be exploited by implementations
on stock hardware to produce fast compiled array accesses.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN:TURKEY):
Rescind the amendment approved at the January 1989 meeting, cited above,
thereby restoring and approving the proposal ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY
to its state as of version 4.
Furthermore make the following change: the behavior of :ADJUSTABLE NIL,
explicitly supplied, may differ from the behavior of omitting the
:ADJUSTABLE argument in some implementations.
Implementations may be divided into three kinds, according to the behavior
of MAKE-ARRAY when given :ADJUSTABLE NIL or when :ADJUSTABLE is omitted:
(1) Always return a non-adjustable array.
(2) Always return an adjustable array.
(3) Sometimes return one kind, sometimes another.
In implementations of kind (1), a declaration that an array is simple
(using the SIMPLE-ARRAY, SIMPLE-VECTOR, SIMPLE-STRING, or SIMPLE-BIT-VECTOR
type specifier) may be taken literally: it is a guarantee that the array
in question will be, among other things, not adjustable. The compiler in
such an implementation may rely on this declaration to produce good
compiled code.
In implementations of kinds (2) and (3), a declaration that an array
is simple is understood a little bit differently: it constitutes a
guarantee by the user that he made a good-faith effort to create a
simple array, that is, MAKE-ARRAY was given an *explicit* argument
:ADJUSTABLE NIL. The compiler for an implementation of kind (2) will
know that its arrays are always adjustable anyway and can generate code
accordingly. The compiler for an implementation of kind (3) may throw
up its hands, or it may use implementation-specific knowledge about
the behavior of MAKE-ARRAY to determine what code to produce; for example,
an implementation of kind (3) might provide non-adjustable strings but
not provide non-adjustable general arrays.
Therefore there is a difference between using :ADJUSTABLE NIL and omitting it;
using it entitles the user to make certain type declarations, whereas
omitting it does not entitle the user to make such type declarations.
Implementations of kind (3) might choose to interpret an explicit passing
of :ADJUSTABLE NIL as requiring a non-adjustable array, but an omission as
leaving the implementation free to make the choice; but this is only one
of many permitted interpretations.
Nevertheless, ADJUSTABLE-ARRAY-P is the sole run-time arbiter of whether
or not ADJUST-ARRAY will succeed.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN:MONKEY):
Rescind the amendment approved at the January 1989 meeting, cited above,
thereby restoring and approving the proposal ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY
to its state as of version 4.
Implementations may be divided into three kinds, according to the behavior
of MAKE-ARRAY when given :ADJUSTABLE NIL or when :ADJUSTABLE is omitted:
(1) Always return a non-adjustable array.
(2) Always return an adjustable array.
(3) Sometimes return one kind, sometimes another.
This proposal forbids implementations of kind (3).
In implementations of kind (1), a declaration that an array is simple
(using the SIMPLE-ARRAY, SIMPLE-VECTOR, SIMPLE-STRING, or SIMPLE-BIT-VECTOR
type specifier) may be taken literally: it is a guarantee that the array
in question will be, among other things, not adjustable. The compiler in
such an implementation may rely on this declaration to produce good
compiled code.
In implementations of kind (2), a declaration that an array
is simple is understood a little bit differently: it constitutes a
guarantee by the user that he made a good-faith effort to create a
simple array, that is, MAKE-ARRAY was not given :ADJUSTABLE <non-NIL>.
The compiler for an implementation of kind (2) will
know that its arrays are always adjustable anyway and can generate code
accordingly.
ADJUSTABLE-ARRAY-P is the sole run-time arbiter of whether
or not ADJUST-ARRAY will succeed.
Rationale:
It is silly to play a semantic game wherein one might or might not
be able to adjust an array terminologically defined to be "adjustable".
It is recognized that implementations differ on whether and when arrays
are to be adjustable, and that this state of affairs is desirable, being
motivated not only by inertia but by questions of flexibility and
efficiency as a function of hardware. The hope is that by being just a
little more explicit about the permitted range of implementation options
we can provide a more useful semantics for ADJUSTABLE-ARRAY-P and for
array type declarations.
Current practice:
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL (or omitted) arrays
non-adjustable, and therefore are compatible with either proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases
and I believe it does not depend on type declarations of simple arrays,
and therefore is compatible with either proposal.
Cost to implementors:
Perhaps some implementation would have to change, but I don't know of any.
Cost to users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect; in particular, ADJUSTABLE-ARRAY-P
really would mean "can I adjust this array?"
Aesthetics:
The status quo is yukky.
Discussion:
Steele favors ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN:MONKEY, but fears that
there may be some implementation of kind (3) out there that is of kind (3)
for some important reason. Proposal TURKEY has been provided to cover
that contingency.
∂02-Feb-89 0532 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Feb 89 05:32:06 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02816g; Thu, 2 Feb 89 05:14:51 PST
Received: by bhopal id AA28172g; Thu, 2 Feb 89 05:15:43 PST
Date: Thu, 2 Feb 89 05:15:43 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8902021315.AA28172@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, KMP@STONY-BROOK.SCRC.Symbolics.COM,
jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, masinter.pa@Xerox.COM,
cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Fri, 27 Jan 89 20:51 EST <19890128015132.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue PROCLAIM-LEXICAL
re:
... provided that we can guarantee that you would never have to
access the symbol's global value when there is a special binding of
the variable. I believe this was the purpose of the amendment that
. . .
I believe that the reason people have this goal is not at all an issue
of desired language semantics, but instead that they believe it would be
too difficult in a shallow-bound implementation to allow access to the
global value in the presence of special bindings. I used to believe
that too, but I figured out that the implementation expense can be very
small. Here is why: . . .
This topic has had enormous amounts of discussion a long time ago.
Perhaps you weren't party to the discussions back then, by my objection
-- shared by several others (e.g. Julian Padgett?) -- is *** not
at all *** on the performance implications. In fact, in the earlier
discussion, I likened the algorithm for global-lexical access in
shallow bound implementations as a "dual" to that for dynamic access
in a deep bound implementation; efficient algorithms for this problem
have been known for nearly 15 years or more.
Now, QLISP is a deep bound implementation, and thus already has these
algorithms working (patterened, not unsurprisingly, after some of
the Interlisp work). But we strongly feel that there should not be
two conceptually different "top level" environments -- a global-lexical
one and a global-dynamic one. The counter argument that these would
be implemented as exactly the same set of value cells is not relevant.
Our feeling (if indeed I speak for some of the other objectors) is that
local lexical overrides of global proclamations are acceptable; the
override has only tightly constrained lexical scope. Thus a local
"lexical" declaration for a variable proclaimed to be SPECIAL is
not troublesome. But an override of either a SPECIAL or a GLOBAL
proclamation that has indefinite scope (yes "scope", not extent) is a
terribly bad and confusing idea. A special declaration or binding of
a variable globally proclaimed LEXICAL (or, GLOBAL as in QLISP's case)
would be such a violation.
-- JonL --
∂02-Feb-89 0807 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 2 Feb 89 08:07:47 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05472; 2 Feb 89 15:31 GMT
Date: Thu, 2 Feb 89 15:46:17 GMT
Message-Id: <8811.8902021546@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue PROCLAIM-LEXICAL
To: Jon L White <@sail.stanford.edu:jonl@lucid.com>,
Moon@scrc-stony-brook.arpa
Cc: sandra <@cs.utah.edu:sandra@defun>, KMP@scrc-stony-brook.arpa,
masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
> This topic has had enormous amounts of discussion a long time ago.
> Perhaps you weren't party to the discussions back then, by my objection
> -- shared by several others (e.g. Julian Padgett?) -- is *** not
> at all *** on the performance implications.
Some of the objections at he Hawaii meeting were definitely about
the performance implications, and also the question of whether the
"bit" needed for the flag can actually be found. (At least one person
said they didn't have a free bit.)
I am having difficulty understanding the "conceptual" argument.
It seems that you end up with local lexical being able to override
proclaimed special but not the other way around. The LG proposal is
at least symmetric.
And, as I tried to say in an earlier message, the reasonable uses
of GLOBAL are subsumed by LEXICAL.
> Now, QLISP is a deep bound implementation, and thus already has these
> algorithms working (patterened, not unsurprisingly, after some of
> the Interlisp work). But we strongly feel that there should not be
> two conceptually different "top level" environments -- a global-lexical
> one and a global-dynamic one. The counter argument that these would
> be implemented as exactly the same set of value cells is not relevant.
Conceptually, there is one global environment in the LG proposal.
That's how the proposal's stated, at least, and I do think you can
coherently think of it that way.
> Our feeling (if indeed I speak for some of the other objectors) is that
> local lexical overrides of global proclamations are acceptable; the
> override has only tightly constrained lexical scope. Thus a local
> "lexical" declaration for a variable proclaimed to be SPECIAL is
> not troublesome. But an override of either a SPECIAL or a GLOBAL
|
Do you mean LEXICAL here -------------------------| ?
You just said a lexical declaration for a variable proclaimed special
was OK; so if you don't mean LEXICAL, there's a contradiction.
> proclamation that has indefinite scope (yes "scope", not extent) is a
> terribly bad and confusing idea. A special declaration or binding of
> a variable globally proclaimed LEXICAL (or, GLOBAL as in QLISP's case)
> would be such a violation.
Case 1: (let ((a 10))
(let ((a 20))
(declare (special a)) ;override lexical
...)
...)
Case 2: (define-lexical a 10)
(let ((a 20))
(declare (special a))
...)
Why are these two cases different? Both set up a new scope in which
the variable A is special instead of lexical. Both do it inside
another scope where the variable is lexical.
I think these two cases should be analogous. The only reason that
they should not be (that I can see) is that PROCLAIM is somehow
"more magic" than placing the corresponding declaration on every
binding. And if it is "more magic", I think it should not be.
-- Jeff
∂02-Feb-89 1239 CL-Cleanup-mailer Issue: FUNCTION-NAME (Version 1)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 2 Feb 89 12:39:51 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA12354; Thu, 2 Feb 89 12:39:31 PST
Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA28202; Thu, 2 Feb 89 12:36:18 PST
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
id AA00560; Thu, 2 Feb 89 12:39:12 PST
Date: Thu, 2 Feb 89 12:39:12 PST
From: jrose@Sun.COM (John Rose)
Message-Id: <8902022039.AA00560@lukasiewicz.sun.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU,
Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Fri, 27 Jan 89 22:48 EST <19890128034814.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-NAME (Version 1)
I favor the FUNCTION-NAME:LARGE proposal, because it defines a single,
useful notion of what a function name is. The other proposals have
the flaw that there are two kinds of function names: symbols, and
extended names, with only some of the Lisp primitives accepting the
latter. This may be convenient for some implementations, for the
short term, but it fragments the language.
I have two other comments on the proposal.
A. Reducing the Cost to Implementors
One observation you could put in the Cost To Implementors section is
that none of the SMALL, MEDIUM, or LARGE proposals require changes to
the "guts" of the interpreter and compiler. This is because an
implementation is free to use plain symbols internally to name
functions, and use a hack like JonL's SETF:|3.FOO.BAR| mapping to
convert non-symbol names to symbols. This conversion would be done as a
part of parsing the handful of forms which accept function names, and
then all other passes of the interpreter and compiler (the "guts") would
just see symbols. (By "parsing" I mean ensuring the right number and
type of syntactic subforms. You can see that this is a very early and
simple stage of processing.) Or, Lisp compilers with an "alphatization"
phase could perform function name symbolization at that phase.
B. Finishing the Job of Regularization
I'd like to suggest two additions to your smorgasbord of options in the
FUNCTION-NAME:LARGE section of the proposal. One addition would
regularize a major special case of functions--lambda expressions. The
other addition would reaffirm an unstated regularity in the language,
that function names can stand in for functions under FUNCALL and APPLY.
Not only can the treatment of symbolic and setf-list function names be
regularized, but lambda too can be treated in a consistent manner.
If these two points are added to your proposal, the language as a whole
would have a completely uniform treatment of functions and function
names. Here they are:
13. Declare that any function name is a suitable argument to FUNCALL and
APPLY. In such a case, the function name is passed to FDEFINITION,
and the result (which may in turn be a function name) is called.
That is, the following two expressions are equivalent, when fname
is a function name:
(FUNCALL fname x y)
<==>
(FUNCALL (FDEFINITION fname) x y)
Note that the definition is sought in the global environment.
Compare with the rule which applies to a function name occurs,
syntactically, as the car of a list in code:
(fname x y)
<==>
(FUNCALL (FUNCTION fname) x y)
<==> (under proposal item 9)
(FUNCALL (FDEFINITION fname <local-environment>) x y)
12. Declare that any lamba expression (i.e., a list whose car is LAMBDA and
whose cdr is a well-formed lambda argument list and body) is a function
name. The effects of the function name accessors on lambda expressions
are as follows. FDEFINITION returns an implementation-defined value which
is the function specified the lambda expression, closed in the global
environment. This FDEFINITION value cannot be changed by SETF.
FBOUNDP always returns T, and MAKUNBOUND is an error.
Esthetics:
The effect of items 11 and 12 is to complete the regularization of
Common Lisp's treatment of functions and function names. The total
effect of proposal items 1 through 12 is that Lisp has just two notions
for referencing function objects: FUNCTIONS, which are Lisp objects that
directly represent executable code, and FUNCTION NAMES, which can denote
functions. Symbols, SETF function names, and lambda expressions are all
examples of the latter notion. The former notion is highly
implementation dependent. Function names can occur as syntactic
entities in code. FUNCALL and APPLY work uniformly on both functions
and function names, with a consistent semantics.
Lambda expressions are often thought to denote "anonymous" functions, so
it may seem paradoxical to treat them as names. The paradox is only
apparent, since the expression itself has the properties of a Lisp
function name: It is (typically) a cons tree which can be read, printed,
and stored in source files, and it denotes a well-defined Lisp function.
Benefit to Users:
Function names are useful for representing objects in remote
environments, because they need not be bound at all times to the same
function, or to any function, and because they are typically stable in
meaning across reads and prints, where plain functions are not.
Programs which deal simultaneously with remote and local environments,
such as CLOS, can probably be simplified, since function names
can be used uniformly, rather than an ad-hoc mixture of functions
and function names.
The language as a whole become more uniform from these additions and
clarifications, making it easier to learn and use. (See Esthetics.)
Cost to Implementors:
Interpreters which currently have a special case check for application
of lambda expressions would need to modify this check to call
FDEFINITION when a list of any sort is encountered. Note that all
Common Lisps already must perform some such check, since lambda
expressions can be funcalled (and this is currently a very special case,
the only standard case of a list being funcalled). This means that
every Lisp already has a place to insert the required call to
FDEFINITION.
In some implementations, FDEFINITION of a lambda expression could be that
lambda-expression itself. In others featuring a pre-eval codewalk, the
walk would be done by FDEFINITION, which would return an appropriate
closure.
Cost of Non-adoption:
Rather than two notions for function references (functions and function
names), there would be several notions, each corresponding to the valid
inputs for particular group of primitives. APPLY and FUNCALL would
accept functions, symbolic names, and lambda expressions, but not setf
function names. FDEFINITION and its kind would accept symbols and setf
function names but not lambda expressions. If the :LARGE proposal is
not adopted, this fragmentation would also apply to the various syntaxes
involving function names; some names would be acceptable to DEFUN
but not to FLET, etc.
-- John
∂03-Feb-89 0820 CL-Compiler-mailer Re: Issue: FUNCTION-NAME (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Feb 89 08:19:54 PST
Received: by ti.com id AA13550; Fri, 3 Feb 89 10:17:57 CST
Received: from Kelvin by tilde id AA18146; Fri, 3 Feb 89 10:06:53 CST
Message-Id: <2811514004-8355350@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 3 Feb 89 10:06:44 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: jrose@Sun.COM (John Rose)
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU,
CL-Compiler@SAIL.STANFORD.EDU
Subject: Re: Issue: FUNCTION-NAME (Version 1)
In-Reply-To: Msg of Thu, 2 Feb 89 12:39:12 PST from jrose@Sun.COM (John Rose)
> 13. Declare that any function name is a suitable argument to FUNCALL and
> APPLY. In such a case, the function name is passed to FDEFINITION,
> and the result (which may in turn be a function name) is called.
I don't think this is such a good idea. The case of automatically coercing
a symbol to a function is needed because it provides a portable mechanism
for indirect addressing of a function; I haven't seen a reason to need this
for non-symbol function specs. But more important is that coercing a
symbol to a function is a trivial operation that is reasonable to do at
run time on each call without adding a significant amount of overhead.
FDEFINITION, on the other hand, is a much more expensive operation -- at
best it might use GET to do a property list lookup, or it could be using
string-append and INTERN to convert the name to a symbol. In either case,
I think this is more work than you want to do on each call.
> 12. Declare that any lamba expression (i.e., a list whose car is LAMBDA and
> whose cdr is a well-formed lambda argument list and body) is a function
> name. The effects of the function name accessors on lambda expressions
> are as follows. FDEFINITION returns an implementation-defined value which
> is the function specified the lambda expression, closed in the global
> environment. This FDEFINITION value cannot be changed by SETF.
> FBOUNDP always returns T, and MAKUNBOUND is an error.
The exceptions for SETF and MAKUNBOUND show that this is not really as
consistent as you might like. Furthermore, the FUNCTION special form would
have to treat a LAMBDA expression as a function, not a function name, in
order for it to be lexically scoped. It seems like this might just cause
confusion rather than consistency.
∂03-Feb-89 1513 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 89 15:13:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 533462; 3 Feb 89 18:10:54 EST
Date: Fri, 3 Feb 89 18:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <890130100149.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890203231131.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 30 Jan 89 10:01 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Fri, 27 Jan 89 21:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I support version 2 of this. I have a couple of minor comments:
DESTRUCTURING-BIND should not allow &WHOLE any more than it should allow
&ENVIRONMENT. Those two features are specific to macroexpanders.
Sigh. EB sent something which touched on this same issue. I guess you're
right, but I think before we disallow them, we should probably make it
clear that &WHOLE and &ENVIRONMENT only belong at toplevel of a DEFMACRO
lambda list and not within. That would make the implementation-strategy
for DEFMACRO more apparent. I made a separate issue,
DEFMACRO-LAMBDA-LIST, to discuss this.
I committed an error here. &ENVIRONMENT is specific to macroexpanders,
but &WHOLE should be allowed in DESTRUCTURING-BIND just as it is allowed
other than at top level in DEFMACRO. It's just that &WHOLE at top level
in DEFMACRO has a slightly special meaning.
Actually, it seems to me that the same case could be made for &BODY. It
has no purpose in DESTRUCTURING-BIND since an explicit call to
DESTRUCTURING-BIND will never have to affect the way something pretty
prints. Nevertheless, since it is useful to have &BODY appear at recursive
levels of DEFMACRO binding forms, I think it should be permitted here.
Still, we should be up front about our motivations here.
I think it's more consistent to allow &BODY.
Both LOOP and DESTRUCTURING-BIND allow NIL in place of a variable
name as a way of ignoring a portion of the destructured tree, in
Symbolics current practice. I think that's a good idea and should
go in the standard. It's only an abbreviation for a dummy variable
and a DECLARE IGNORE, but the whole destructuring feature is nothing
but an abbreviation anyway.
Note that whichever way we decide, DESTRUCTURING-BIND and DEFMACRO should
be consistent about allowing NIL to mean ignore.
This is ok with me. Does anyone object?
The main difficulty is that NIL in the cdr position has to be treated as
a special case, it can't be the same as an ignored variable in the cdr
position when DESTRUCTURING-BIND (as DEFMACRO does) regards mismatch
of length of a non-dotted list as an error.
X3J13 LOOP, as documented in 89-004, has this feature. However, it is
inconsistent with DEFMACRO and (I think) DESTRUCTURING-BIND, because
LOOP destructuring does not consider list length mismatch an error.
If I hear no objection, this
change will be in the next version.
Upon reflection, I'd like to withdraw the suggestion about NIL. I don't
think it should be put into the standard at this time.
In fact the feature that I really prefer is the one that provides an
automatic DECLARE IGNORE for any variable that is named IGNORE and is
not referenced. For some reason I was hesitant to suggest that; I think
I was being stupid.
∂03-Feb-89 1537 CL-Cleanup-mailer New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 89 15:37:40 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 533496; 3 Feb 89 18:32:12 EST
Date: Fri, 3 Feb 89 18:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN
To: gls@Think.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8902020519.AA03069@sauron.think.com>
Message-ID: <19890203233247.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think both proposals are wrong. Also this issue is being
discussed privately. More comments later.
∂03-Feb-89 1542 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 89 15:41:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 533502; Fri 3-Feb-89 18:40:02 EST
Date: Fri, 3 Feb 89 18:40 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFMACRO-LAMBDA-LIST (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <890130095112.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890203234040.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree with most of DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION,
except I think that part 1b is a mistake. &WHOLE should be
allowed at all levels. The interesting case is
(DEFMACRO DM1B (A (&WHOLE B C &OPTIONAL D) E) ...)
which allows simultaneous access to the THIRD of the whole
form and to the destructuring of that list into C and D.
I don't know what this would be used for exactly, but there
is no cogent reason to forbid it. Contrary to what you say
in the rationale, it does not work to substitute &REST for
&WHOLE here.
Also the example on p.150 uses &WHOLE in a non-top-level
position, so you would be making a definitely incompatible
change if you forbade that.
∂03-Feb-89 1557 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 89 15:57:39 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 533523; Fri 3-Feb-89 18:55:40 EST
Date: Fri, 3 Feb 89 18:55 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFMACRO-LAMBDA-LIST (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19890203234040.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890203185519.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 3 Feb 89 18:40 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I agree with most of DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION,
except ... Contrary to what you say in the rationale, it does
not work to substitute &REST for &WHOLE here. ...
Right. Total (hopefully temporary) brain lapse on my part. Consider the
proposal ammended -- I'll distribute a new writeup hopefully sometime
soon but won't have time to get to it today.
∂03-Feb-89 1602 CL-Cleanup-mailer Re: New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Feb 89 16:01:55 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 FEB 89 15:57:37 PST
Date: 3 Feb 89 15:57 PST
From: masinter.pa@Xerox.COM
Subject: Re: New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN
In-reply-to: gls@Think.COM's message of Thu, 2 Feb 89 00:19:06 EST
To: gls@Think.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890203-155737-2252@Xerox>
Procedurally, I'd rather handle this as a motion to reconsider the previous
version of ADJUST-ARRAY-NOT-ADJUSTABLE rather than as a new issue. My
reason is that at some point we will probably need to release the "passed"
issues as a description to the community as to what we did and why; I'd
rather not leave ADJUST-ARRAY-NOT-ADJUSTABLE as unamended. So I'm happy to
mail out your message with Problem and Proposal, but in the final state,
just have an amended ADJUST-ARRAY-NOT-ADJUSTABLE issue.
This is not terribly important, but we would need a revised version of
ADJUST-ARRAY-NOT-ADJUSTABLE if the motion passes.
∂03-Feb-89 2211 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Feb 89 22:10:49 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 FEB 89 22:08:43 PST
Date: 3 Feb 89 22:06 PST
From: masinter.pa@Xerox.COM
Subject: Issue: APPEND-DOTTED (Version 5)
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890203-220843-2771@Xerox>
This issue was withdrawn, along with the ones it spawned: APPEND-ATOM and
BACKQUOTE-ATOM-ATSIGN-DOT.
At the time, I believe I said we would consider whether we wanted to submit
a more comprehensive set of proposals that would address all of the issues
simultaneously.
I personally have no desire to do so.
I believe that the sentence Problem Description that claims that CLtL is
not adequately clear is incorrect, namely, that elsewhere in CLtL it states
that if an argument is supposed to be a LIST, it means a PROPER LIST unless
otherwise stated. In the case of APPEND, the only case that otherwise
states so is the last argument, and thus, CLtL does specify that it "is an
error" to pass an atom or a dotted list to APPEND as any argument except
the last.
!
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
14-Jan-88, Version 5 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of
what happens if an argument to APPEND is a dotted list. The only case
explicitly mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be any
LISP object, which becomes the tail end of the constructed list. For
example, (append '(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is not a
list, the behavior when any of the other arguments are not lists is not
specified.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the list
to be returned.
In the degenerate case where there is no last cons (i.e., the argument is
NIL) in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument
is a non-list, the result of APPEND or NCONC can be a non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
the same, since these two might legitimately differ in situations involving
dotted lists. As such, deciding which to use is not just a stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number
of implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter). Franz's Allegro Common Lisp
conforms to the proposed behavior except in the case of (NCONC (LIST) 17)
=> 17, where it returns NIL instead of 17.
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted
list. Xerox Common Lisp signals an error on APPEND and implements the
proposed interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those
implementations which don't already implement it. However, implementations
which have microcoded APPEND or NCONC incompatibly may find the small
change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect
only NIL when SAFETY is 0. In this case, depending on implementation
details, requiring an ATOM check rather than a NULL check may slow things
down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and NCONC
can therefore produce dotted lists, some readers may have (incorrectly)
assumed that APPEND and NCONC can reliably deal in general with dotted
lists, something that doesn't appear to be guaranteed by a strict reading.
The proposed extension would happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the
language will depend largely on how they view the relation between lists
and dotted lists. Those who view dotted lists as a special kind of list may
feel differently than those who view lists as a special kind of dotted
list.
Discussion:
The cleanup committee supports this proposal.
∂03-Feb-89 2218 CL-Cleanup-mailer Re: Issue: APPEND-DOTTED (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Feb 89 22:18:01 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 03 FEB 89 22:15:40 PST
Date: 3 Feb 89 22:15 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: APPEND-DOTTED (Version 5)
In-reply-to: masinter.pa's message of 3 Feb 89 22:06 PST
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890203-221540-2781@Xerox>
I had forgotten and misplaced the mail that KMP sent (during the last
flurry) titled APPEND-FIASCO. It certainly lays out the proposals &
alternatives in some detail.
Nevertheless, I'm concerned that we don't have time to really examine the
ramifications, and that we need not and probably shouldn't pursue this now.
∂03-Feb-89 2232 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Feb 89 22:32:31 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 FEB 89 22:30:55 PST
Date: 3 Feb 89 22:30 PST
From: masinter.pa@Xerox.COM
Subject: Issue: CLOS-CONDITIONS (Version 3)
To: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890203-223055-2803@Xerox>
I believe I agreed that the cleanup committee would take over this issue. It was discussed in the Error Committee report at a previous meeting in 1988, but not voted on at the time.
As you can see, there are comments...
----- Begin Forwarded Messages -----
Return-Path: <X3J13-mailer@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 09 OCT 88 02:50:46 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Oct 88 02:30:05 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473546; Sun 9-Oct-88 05:28:47 EDT
Date: Sun, 9 Oct 88 05:28 EDT
From: CL-ERROR-HANDLING@SAIL.Stanford.EDU
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Draft Issue: CLOS-CONDITIONS (Version 3)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <881009052832.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
There's been some disagreement about a couple of details, so this may
change yet again before we ask you to vote on it, but this is the
version that is likely to be presented for comment at the meeting.
The conflict is represented in the writeup by the presence of two
variant proposals, YES-OPTION-A and YES-OPTION-B.
-----
Issue: CLOS-CONDITIONS
References: Condition System (Revision 18)
Category: ADDITION
Edit history: 26-Sep-88, Version 1 by Pitman
06-Oct-88, Version 2 by Pitman
09-Oct-88, Version 3 by Pitman
Status: For Internal Discussion
Problem Description:
The description of the Common Lisp condition system presupposes
only DEFSTRUCT and not DEFCLASS because it was written when
CLOS had not been adopted. It is stylistically out of step with
CLOS in a few places and places some restrictions which are not
necessary if CLOS can be presupposed.
Subproposal (CLOS-CONDITIONS:YES):
[These options are very similar. They agree except as otherwise noted.]
Define that condition types are CLOS classes.
Define that condition objects are CLOS instances.
Permit multiple parent-types to be named in the list of
parent types. Define that these parent types are treated the
same as the superior class list in a CLOS DEFCLASS expression.
Define that slots in condition objects are normal CLOS slots.
Note that WITH-SLOTS can be used to provide more convenient
access to the slots where slot accessors are undesirable.
Functions such as SIGNAL, which take arguments of class names,
are permitted to take class objects. Such class objects must
still be subclasses of CONDITION.
Eliminate the :CONC-NAME option to DEFINE-CONDITION.
Define that condition reporting is mediated through the
PRINT-OBJECT method for the condition type (class) in question,
with *PRINT-ESCAPE* always being NIL. Specifying
(:REPORT fn) in the definition of a condition type C is
equivalent to doing
(DEFMETHOD PRINT-OBJECT ((X c) STREAM)
(IF *PRINT-ESCAPE* (CALL-NEXT-METHOD) (fn X STREAM)))
Proposal (CLOS-CONDITIONS:YES-OPTION-A):
All of subproposal YES, plus the following...
Extend the syntax for a slot in a DEFINE-CONDITION as follows...
- If a symbol is used, DEFINE-CONDITION will by special case
treat this as if (symbol :INITARG keyword :READER reader-name)
were specified instead, where KEYWORD is generated by
(INTERN (SYMBOL-NAME symbol) (FIND-PACKAGE "KEYWORD"))
and reader-name is generated by
(INTERN (FORMAT NIL "~A-~A" condition-type symbol))
for CONDITION-TYPE being the condition type being defined.
- A length 1 list, (symbol), is treated the same as providing
the symbol itself.
- If a length 2 list, (symbol value) is provided, it is treated
as (symbol :INITARG keyword :READER reader-name :INITFORM value),
with KEYWORD and READER-NAME being computed as above.
- If a list of length greater than 2 is used, it is treated
the same as a CLOS slot-specifier. In that case, the :INITARG
and :READER options must be explicitly specified if desired.
This syntax is compatible with the existing semantics of
DEFINE-CONDITION.
Rationale:
This provides maximal compatibilty with the old semantics
for DEFINE-CONDITION, which numerous vendors now distribute.
Further, and perhaps more importantly, the uses of slots in
DEFINE-CONDITION are highly constrained. They are not assigned
so an INITARG is nearly always needed. There are almost
universally accessed externally, so a :READER is usually
needed. This syntax makes what is by far the most convenient
use very syntactically simple.
Proposal (CLOS-CONDITIONS:YES-OPTION-B):
Incompatibly change the syntax of a slot in DEFINE-CONDITION
to be compatible with a DEFCLASS slot specification.
An implication of this change is that forms like
(DEFINE-CONDITION FOO (BAR) ((A 1) (B 2)))
would have to be written
(DEFINE-CONDITION FOO (BAR) ((A :INITARG :A :READER FOO-A :INITFORM 1)
(B :INITARG :B :READER FOO-B :INITFORM 2)))
Rationale: This is most compatible with CLOS.
Examples:
Slot specifiers...
Under YES-OPTION-A ...
A slot specifier of X in condition type FOO is still valid
and means the same as (X :INITARG :X :READER FOO-X).
A slot specifier of (X) in condition type FOO is still valid
and means the same as (X :INITARG :X :READER FOO-X).
A slot specifier of (X V) in condition type FOO is still
valid and means the same as
(X :INITARG :X :READER FOO-X :INITFORM V).
In addition, other slot specifiers such as
(X :INITARG :EX :TYPE FIXNUM)
are permitted as in DEFCLASS.
Under YES-OPTION-B ...
A slot specifier of X is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X) is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X V) would no longer be valid.
In addition, other slot specifiers such as
(X :INITARG :EX :TYPE FIXNUM)
are permitted as in DEFCLASS.
Conc names ...
(DEFINE-CONDITION FOOBAR (FOO BAR) (X Y) (:CONC-NAME FUBAR))
would be rewritten
(DEFINE-CONDITION FOOBAR (FOO BAR)
((X :INITARG :X :READER FUBAR-X)
(Y :INITARG :Y :READER FUBAR-Y)))
Report methods ...
(DEFINE-CONDITION OOPS (ERROR) ())
(DEFMETHOD PRINT-OBJECT ((X OOPS) STREAM)
(IF *PRINT-ESCAPE*
(CALL-NEXT-METHOD)
(FORMAT STREAM "Oops! Something went wrong.")))
(ERROR 'OOPS)
>>Error: Oops! Something went wrong.
Rationale:
These changes are consistent with the intent of the recent
X3J13 endorsement of CLOS and the Common Lisp Condition System.
The shorthand notations for DEFINE-CONDITION's slots spec
are justified since the the way in which condition slots are
used is much more highly constrained than for arbitrary classes.
This means we can predict what will be the common case and make
it far more syntactically convenient than it might otherwise be.
Although flushing :CONC-NAME is an incompatible change, nothing
forbids an implementation from supporting it as an extension
during a transition period.
Current Practice:
Some implementations supporting CLOS probably already do this,
or something very similar.
Cost to Implementors:
If you really have CLOS, this is very straightforward.
Cost to Users:
Small, but tractable.
The main potential problems are:
- :CONC-NAME. There is nothing that keeps an implementation from
continuing to support :CONC-NAME for a short while until old code
has been upgraded.
- The incompatible change to slot syntax. Again, it is possible to
unambiguously recognize a 2-list as old-style syntax and an
implementation can provide interim compatibility support during
a transition period.
Even if implementations did not provide the recommended compatibility
support, users could trivially shadow DEFINE-CONDITION and provide the
support themselves, expanding into the native DEFINE-CONDITION in the
proper syntax.
Cost of Non-Adoption:
Conditions will seem harder to manipulate than other user-defined types.
People will wonder if CLOS is really something we're committed to.
Benefits:
A more regular language.
Aesthetics:
Anything that makes the language more regular improves the aesthetics.
Discussion:
People seem to disagree about the status that CLOS might occupy
in the upcoming standard. In spite of a vote of support, they seem
to think it might be optional in some way. Passing this proposal
establishes a clear precedent for the full integration of CLOS into
the emerging language.
Moon suggests that we might want to add condition types for the errors
CLOS might signal. It isn't obvious (to Pitman, at least) that this
change is as straightforward as it looks, though, so it will have to
come up under separate cover.
Richard Mlynarik suggests adding a generic function, REPORT-CONDITION,
which is used for reporting conditions. It is possible to discuss such
a generic function as a separate issue layered atop the substrate which
this proposal provides, so that issue has been deferred.
Pitman supports this change, with mild preference for YES-OPTION-A.
Gregor supports this change, with strong preference for YES-OPTION-B.
----- Next Message -----
Return-Path: <Mly%AI.AI.MIT.EDU@XX.LCS.MIT.EDU>
Received: from XX.LCS.MIT.EDU ([10.0.0.44]) by Xerox.COM ; 30 OCT 88 11:34:02 PST
Received: from NICKB.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 30 Oct 88 14:32-EST
Date: Sun, 30 Oct 88 14:34 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Re: Draft Issue: CLOS-CONDITIONS (Version 3)
To: masinter.pa
cc: gregor.pa
In-Reply-To: <881026-153859-14085@Xerox>
Included-msgs: <19881007052142.8.MLY@JACKIE.AI.MIT.EDU>
Message-ID: <19881030193406.7.MLY@NICKB.AI.MIT.EDU>
Character-Type-Mappings: (1 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI")
Fonts: CPTFONT, CPTFONTI
Date: 26 Oct 88 15:38 PDT
From: masinter.pa@Xerox.COM
I thought there might be a way to word this proposal in a way that would
make the error/signal system *compatible* with CLOS but not to actually
make it require the low-level implementation to *use* CLOS if it didn't
want to. Many vendors are only now working on integrating CLOS into their
environment. A lot of the concern is for "staging" the introduction of CLOS
and the condition system. This is also a concern for those with existing
implementations where they might want to load in the CLOS support late in
the system-building process, and yet use the condition system early in that
process. While this is an implementation detail, the implementation
ramifications of your proposal need to be spelled out.
[...]
I sent the following comments to Pitman.
I guess I don't really care that much about this anymore, since I think
that the error Standard is pretty broken. The phrase ``swimming up
waterfalls'' comes to mind.
Date: Fri, 7 Oct 88 01:21 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Subject: Issue: CLOS-CONDITIONS (Version 2)
To: KMP@STONY-BROOK.SCRC.SYMBOLICS.COM
cc: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM
In-Reply-To: <881006162757.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881007052142.8.MLY@JACKIE.AI.MIT.EDU>
[Mailing list removed]
I had promised myself that I would have no more to do with this
Error Standard but nevertheless...
Date: Thu, 6 Oct 88 16:27 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
The description of the Common Lisp condition system presupposes
only DEFSTRUCT and not DEFCLASS because it was written when
CLOS had not been adopted. It is stylistically out of step with
CLOS in a few places and places some restrictions which are not
necessary if CLOS can be presupposed.
Proposal (CLOS-CONDITIONS:YES):
Define that condition types are CLOS classes.
Define that condition objects are CLOS instances.
This is certainly desirable. However, it ignores a pragmatic problem:
* Even though CLOS has been adopted, it is not widely supported.
(Support means `supplied by vendors' rather than `you can use PCL')
* The error system is much simpler to implement than CLOS.
The error system is perceived to be more critical than CLOS.
(For example, I believe that Lucid supply an implementation of
something like KMP's error system in their 3.0 Lisp release. They do
not supply any CLOS or CLOS-precursor support as far as I know.)
Therefore...
It would be nice if the standard were worded in such a way that it
allowed a non-CLOS implementation. Given that the only
`object-oriented' features that the error standard requires are
* TYPEP
* slot inheritance
* report-function inheritance (with no method-combination)
and since it is very easy to write a toy class system which implements
just those features, let me suggest that the DEFINE-CONDITION macro not
implicitly define :READERs. Readers presuppose CLOS generic functions a
little too much. I feel that a better (interim -- all discussion here
is interim) solution would be to define the function SLOT-VALUE in the
spec. KMP-CONDITION-SYSTEM:SLOT-VALUE will be EQ CLOS:SLOT-VALUE in
Lisp implementations which include a CLOS implementation.
Please note that I am in no way trying to deprecate acceptance or usage
of CLOS -- I want to see it as an integral part of Common Lisp
(especially if define-method-combination worked properly by using
closures instead of manipulating list structure... :-)
Permit multiple parent-types to be named in the list of
parent types. Define that these parent types are treated the
same as the superior class list in a CLOS DEFCLASS expression.
You should explicitly state that the class precedence list is computed
in the way CLOS specifies.
Extend the syntax for a slot in a DEFINE-CONDITION as follows...
- If a symbol is used, DEFINE-CONDITION will by special case
treat this as if (symbol :INITARG keyword :READER reader-name)
were specified instead, where KEYWORD is generated by
(INTERN (SYMBOL-NAME symbol) (FIND-PACKAGE "KEYWORD"))
and reader-name is generated by
(INTERN (FORMAT NIL "~A-~A" condition-type symbol))
for CONDITION-TYPE being the condition type being defined.
- A length 1 list, (symbol), is treated the same as providing
the symbol itself.
- If a length 2 list, (symbol value) is provided, it is treated
as (symbol :INITARG keyword :READER reader-name :INITFORM value),
with KEYWORD and READER-NAME being computed as above.
- If a list of length greater than 2 is used, it is treated
the same as a CLOS slot-specifier. In that case, the :INITARG
and :READER options must be explicitly specified if desired.
I think that this is highly undesirable wording to place in the
specification (but then, it wouldn't be the first time I've thought
that.)
I really don't think that your Standard is entrenched far enough
that backwards compatibility is an issue in its definition. Note that
whether individual ε1implementationsε0 wish to offer such a
backward-compatibility feature is a different matter.
DEFINE-CONDITION (like statice:define-entity-type...) should require the
use of the standard :INITFORM option. I'm of two minds about whether
DEFINE-CONDITION should default the :INITARG. I lean towards having it
do so, with the prosiso that the initarg be exactly the symbol, *NOT* a
keyword. My reasons for this are as follows:
* I can't think of a single case in which it is undesirable for the
caller of MAKE-CONDITION to be able to specify the value of a slot.
* Given that there exists a DEFINE-CONDITION macro (distinct from
DEFCLASS) we might as well make it do things that are useful for
conditions. (While we're at it, we should make it support
:required-initargs -- only 1/4 joking.)
I think this argues for defaulting the :INITARG option.
* (intern ... (find-package "KEYWORD")) is just asking for disaster.
Major disaster. The sort of disaster which non-keyword initargs were
invented to avoid in the first place. Just Say No!
(BTW, this doesn't pose much of a compatibility problem. A
backwards-compatible DEFINE-CONDITION can recognise
slot-specifications of the obsolete forms <name> and (<name> <initform>)
and default the :INITARG in these cases to the losing keyword.
There remains the problem of (<name>)...)
Functions such as SIGNAL, which take arguments of class names,
are permitted to take class objects.
Presumably it is an error to pass something which is not a subclass of
CONDITION.
Eliminate the :CONC-NAME option to DEFINE-CONDITION.
Strongly agreed.
Define that condition reporting is mediated through the
PRINT-OBJECT method for the condition type (class) in question,
with *PRINT-ESCAPE* always being NIL. Specifying
(:REPORT fn) in the definition of a condition type C is
equivalent to doing
(DEFMETHOD PRINT-OBJECT ((X c) STREAM)
(IF *PRINT-ESCAPE* (CALL-NEXT-METHOD) (fn X STREAM)))
I think that this is a very bad move.
A much better idea is the define something like DBG:REPORT, which is
only called in the PRINC case. Otherwise every time a user wants to
write a method to affect the way a condition reports itself she must go
through the (if *print-escape* (call-next-method) ...) crap.
I suggest
(defgeneric report-condition (condition stream &key verbosely))
[BTW the reason for the :VERBOSELY keyword is in case you have ever seem
the error messages from ILA-NFS -- there is no way to control whether
they print a dozen lines explaining every possible conceivable cause of
the problem (which is appropriate when the debugger is entered, for
example) or whether they should just summarise the problem (which is
appropriate when the ":Copy File" command reports that it was unable to
copy one particular file.)]
Having the :VERBOSELY keyword can't hurt anything, and it provides a way
to avoid horrible inappropriate verbosity.
Another reason for defining a new generic function and not reusing
PRINT-OBJECT is that that ε1doesε0 provide a way to add extra options like
:VERBOSELY.
Examples:
[...]
Report methods ...
(DEFMETHOD PRINT-OBJECT ((X OOPS) STREAM)
(IF *PRINT-ESCAPE*
(CALL-NEXT-METHOD)
(FORMAT STREAM "Oops! Something went wrong.")))
I think this is a good example of the lossage I described above.
[...]
Discussion:
People seem to disagree about the status that CLOS might occupy
in the upcoming standard. In spite of a vote of support, they seem
to think it might be optional in some way. Passing this proposal
establishes a clear precedent for the full integration of CLOS into
the emerging language.
As I said above, I completely agree with this. However, the pragmatics
of the next year or so -- in which users will likely be offered
vendor-supported Error Standard implementations but not vendor-supported
CLOS -- argue for the sort of minor change I suggested above.
Finally, in <881006184006.0.KMP@BOBOLINK.SCRC.Symbolics.COM> you reply
to Gregor:
Also, it's no different than what DEFSTRUCT does, so it's not like this
is the only place in the language following those rules. Have you
submitted a proposal to deprecate DEFSTRUCT?
I think this is a highly spurious argument. There is no reason to prepetuate
the bad design of DEFSTRUCT. (I have never heard anybody argue that the
mandatory default-value in defstruct slot syntax is anything but a
mistake.)
----- End Forwarded Messages -----
∂03-Feb-89 2243 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Feb 89 22:43:42 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 FEB 89 22:42:11 PST
Date: 3 Feb 89 22:41 PST
From: masinter.pa@Xerox.COM
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 6)
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Line-fold: NO
Message-ID: <890203-224211-2829@Xerox>
At the January meeting, my notes are only "amended to return T
on closed streams" without an exact wording change.
This is the issue as reworded. Do you see any need to remail
this to X3J13?
!
Status: Passed, Jan 89 X3J13
Forum: Cleanup
Issue: CLOSED-STREAM-OPERATIONS
References: CLOSE (CLtL p 332)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
8-Oct-88, Version 2 by Masinter
13-Oct-88, Version 3 by van Roggen
1-Dec-88, Version 4 by Pitman
5-Dec-88, Version 5 by Masinter (separate other issues)
3-Feb-89, Version 6 by Masinter (as per Jan 89 X3J13)
Related Issues: STREAM-ACCESS, STREAM-INFO, INPUT-STREAM-P-CLOSED,
CLOSE-CONSTRUCTED-STREAMS, PATHNAME-STREAM
Problem Description:
The description of CLOSE is not completely clear about the functions
which are allowed to be performed on a closed stream.
On p332 it says:
``The stream is closed. No further Input/output operations may be
performed on it. However, certain inquiry operations may still
be performed, ...''
but the list of inquiry operations is not specified.
Proposal (CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY)
Clarify the behavior of the following functions on closed streams:
* STREAMP is unaffected by whether its stream argument is open or closed.
* CLOSE can be called on any stream, whether open or closed, and
will always return T.
* PATHNAME is valid on either an open or closed stream. Since some
implementations cannot provide the truename of a file until the
file is closed, it would in principle be possible for PATHNAME in
some implementations to return more specific information after the
stream is closed. For consistency, however, PATHNAME is prohibited
from doing this. PATHNAME must return the same pathname after a
file is closed as it did before. (The passed proposal in issue
PATHNAME-STREAM still stands.)
* TRUENAME is valid on either an open or closed stream. Since some
implementations cannot provide the truename of a file until the
file is closed, it is permissible TRUENAME to return more specific
information after the stream is closed.
* MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY,
PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING,
FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING,
ENOUGH-NAMESTRING, and OPEN are valid on either open or closed streams.
For any of these operations, using a stream, S, as an argument
where appropriate is equivalent to using (PATHNAME s). See the
description of PATHNAME above to understand the consequences of this.
* PROBE-FILE and DIRECTORY are valid on either open or closed streams.
For either of these operations, using a stream, S, as an argument
where appropriate is equivalent to using (PATHNAME s). See the
description of PATHNAME above to understand the consequences of this.
In this case of these operators however, closed stream may well be the
most reliable arguments in some cases, since treatment of open streams
to the file system may vary considerably between implementations.
For example, in some operating systems, open files are written under
temporary names and not renamed until close and/or are held invisible
until a close is performed. In general, any code with an intent to be
highly portable should tread lightly when using PROBE-FILE or
DIRECTORY.
Rationale:
One can consider many characteristics of a stream to be independent of
the ability to do I/O. Being able to determine a stream's direction and
its name is often useful for debugging. A number of the descriptions in
CLtL imply (weakly) the ability to work on closed streams. Functions
such as OPEN and DIRECTORY don't really depend on the stream, but on
the name of the stream.
Current Practice:
At least two implementations differ in which functions are allowed to be
performed on a closed stream.
Cost to Implementors:
Unknown, but likely to be small in most implementations.
A nontrivial amount of work may be necessary if the pathname information
is held externally and is normally deleted when the stream is closed.
The implementation will have to copy the information at some time for later
inquiries.
Cost to Users:
Likely to be small; users of an implementation forced to change
by this proposal might have to make some modifications to make their
programs portable.
Benefits:
These clarifications will assist users in writing portable code.
Aesthetics:
Most people will probably see these clarifications as an improvement
in aesthetics.
Discussion:
There are some separate, but related, issues regarding what CLOSE
should do on composite streams or constructed streams such as
created by MAKE-BROADCAST-STREAM. These issues will be addressed
in a separate issue (CLOSE-CONSTRUCTED-STREAMS).
There was some discussion on whether INPUT-STREAM-P and OUTPUT-STREAM-P
should return "false" on a stream that had been closed. The issue
STREAM-ACCESS contains a proposal to add a function OPEN-STREAM-P
which might be useful for the same purpose. This issue was separated
out into a separate issue (INPUT-STREAM-P-CLOSED).
The other functions in proposal STREAM-ACCESS:PROVIDE should
work on closed streams.
The functions in STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS should
not be requred to work on closed streams.
----- End Forwarded Messages -----
∂03-Feb-89 2257 CL-Cleanup-mailer Re: Issue: CLOSED-STREAM-OPERATIONS (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Feb 89 22:57:33 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 FEB 89 22:56:02 PST
Date: 3 Feb 89 22:55 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CLOSED-STREAM-OPERATIONS (Version 6)
In-reply-to: masinter.pa's message of 3 Feb 89 22:41 PST
To: cl-cleanup@sail.stanford.edu, maida@ibm.com
Message-ID: <890203-225602-2835@Xerox>
One reason to send it out to X3J13 is to arbitrate on our notes. I notice
that Moon's notes say "Accepted with amendment that CLOSE of a closed
stream returns NIL".
Mary (or anyone else): do you have a record of the amendment & vote on
issue CLOSED-STREAM-OPERATIONS?
∂05-Feb-89 1111 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Feb 89 11:11:03 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 FEB 89 11:07:33 PST
Date: Sun, 5 Feb 89 11:07 PST
From: Gregor.pa@Xerox.COM
Subject: Issue: CLOS-CONDITIONS (Version 3)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <890203-223055-2803@Xerox>
Message-ID: <19890205190724.0.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
This needs to say a little bit more than that condition types are CLOS
classes. We already new they were classes since they were types defined
by defstruct.
What we need to know is what the metaclass is. That is crucial
information because it is what allows people to include classes that
were not defined with define-condition in their condition classes.
BTW, if you want a concise version of my rational for B over A its:
"The best argument for adding list function specifiers to the
language was to avoid the problems caused by automaticall
creating and interning symbols. That argument must also be
strong to eliminate automatically generated symbols from
define-condition."
-------
∂05-Feb-89 1519 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 89 15:19:16 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA18442@EDDIE.MIT.EDU>; Sun, 5 Feb 89 18:17:37 EST
Received: by spt.entity.com (smail2.5); 5 Feb 89 18:09:14 EST (Sun)
To: cl-cleanup@sail.stanford.edu
Subject: issue PROCLAIM-LEXICAL
Message-Id: <8902051809.AA16827@spt.entity.com>
Date: 5 Feb 89 18:09:14 EST (Sun)
From: gz@spt.entity.com (Gail Zacharias)
There seem to be three somewhat separate extensions being considered in
this proposal.
First is a declaration for variable bindings which allows you to request
a lexical binding, shadowing SPECIAL proclaimations for bindings, e.g.
(proclaim '(special *x*))
(let ((*x* nil)) (declare (lexical *x*)) .. *x* ..)
This introduces no new lookup mechanisms or binding environments, and
a lot of users are asking for it, so it seems pretty uncontroversial.
Second is a declaration for variable references which allows you to request
a reference to the lexical binding of a variable, shadowing SPECIAL
declarations for references, e.g.
(let ((x 'lexical))
(locally (declare (special x))
... (locally (declare (lexical x)) x) ...))
This introduces no new concepts whatsoever, being equivalent to:
(let ((x 'lexical))
(flet ((lexical-x () x))
(locally (declare (special x))
... (lexical-x) ...)))
so I would think it would be uncontroversial as well.
Finally there is the question of a declaration/proclamation which applies to
free variable references (i.e. not referring to a lexical binding), which
in the current proposal introduces LG lookup allowing you to "close over"
global values of variables. This is a new a new concept to Common Lisp,
and is clearly controversial.
I think it would be a good idea to put the first two extensions in a separate
proposal so they don't get lost or mangled in the controversy over LG lookup.
LG lookup can then be considered as an additional extension. This seems better
than putting it all in one proposal and then waging the battle over the LG
aspect in an endless stream of possibly incompatible amendments.
∂05-Feb-89 1841 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Feb 89 18:41:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 533922; Sun 5-Feb-89 21:39:41 EST
Date: Sun, 5 Feb 89 21:40 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <890118142113.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890206024019.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I strongly favor this proposal; it removes the major objection that I
had to the CL condition system as it developed.
However, I don't favor the COPY-CONDITION function. I don't think it's
necessary. More importantly, you have not proposed any concrete specification
of what it does, and unless someone does, it cannot be included in the
language. Fortunately, I think we can just drop it, as I doubt that any
portable program would use it in any significant way that could not just
as well be done with a tiny amount of code using other existing primitives.
I'd like to suggest for consideration a change to the arglist of the
SIGNAL-WITH-RESTARTS and ERROR-WITH-RESTARTS macros. I'm not so sure that
my suggestion is a good one, however the issue I'm addressing is real:
these new macros are syntactically cumbersome, compared to the SIGNAL
and ERROR functions, because you have to write an explicit call to
MAKE-CONDITION. This may encourage programmers not to use these new
macros, instead they might wrap a WITH-RESTARTS around a call to SIGNAL
or ERROR, which looks equivalent to SIGNAL-WITH-RESTART except for having
a nicer syntax, but fails to take advantage of your new feature of
association between restarts and conditions. My suggestion is to
change the first subform of SIGNAL-WITH-RESTARTS and ERROR-WITH-RESTARTS;
currently it is a form that evaluates to a condition. Instead, I propose
that it be a list of forms whose values are used as the arguments to
SIGNAL or ERROR or used in an equivalent fashion. That way if you want
to use MAKE-CONDITION, you have to use one extra pair of parentheses, but
you can use all the other convenience features of SIGNA and ERROR such
as format strings.
∂06-Feb-89 0841 CL-Cleanup-mailer New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Feb 89 08:41:29 PST
Received: from fafnir.think.com by Think.COM; Mon, 6 Feb 89 11:28:47 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 6 Feb 89 11:37:12 EST
Received: by verdi.think.com; Mon, 6 Feb 89 11:36:43 EST
Date: Mon, 6 Feb 89 11:36:43 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902061636.AA27928@verdi.think.com>
To: masinter.pa@xerox.com
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 3 Feb 89 15:57 PST <890203-155737-2252@Xerox>
Subject: New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN
Date: 3 Feb 89 15:57 PST
From: masinter.pa@xerox.com
Procedurally, I'd rather handle this as a motion to reconsider the previous
version of ADJUST-ARRAY-NOT-ADJUSTABLE rather than as a new issue. My
reason is that at some point we will probably need to release the "passed"
issues as a description to the community as to what we did and why; I'd
rather not leave ADJUST-ARRAY-NOT-ADJUSTABLE as unamended. So I'm happy to
mail out your message with Problem and Proposal, but in the final state,
just have an amended ADJUST-ARRAY-NOT-ADJUSTABLE issue.
This is not terribly important, but we would need a revised version of
ADJUST-ARRAY-NOT-ADJUSTABLE if the motion passes.
Fine. By the way, as a result of discussions with RPG this weekend,
I have concluded that the solutions I offered are themselves broken.
However, I still believe that there is a problem to be solved here.
--Guy
∂06-Feb-89 0845 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Feb 89 08:45:00 PST
Received: from fafnir.think.com by Think.COM; Mon, 6 Feb 89 11:32:08 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 6 Feb 89 11:40:40 EST
Received: by verdi.think.com; Mon, 6 Feb 89 11:40:11 EST
Date: Mon, 6 Feb 89 11:40:11 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902061640.AA27962@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 3 Feb 89 18:11 EST <19890203231131.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND (Version 2)
Date: Fri, 3 Feb 89 18:11 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
...
In fact the feature that I really prefer is the one that provides an
automatic DECLARE IGNORE for any variable that is named IGNORE and is
not referenced. For some reason I was hesitant to suggest that; I think
I was being stupid.
Presumably you want the additional special treatment that such
variables named IGNORE are exempt from the prohibition on the same
variable appearing twice in a lambda-list.
--Guy
∂06-Feb-89 0851 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 6)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Feb 89 08:50:55 PST
Received: from fafnir.think.com by Think.COM; Mon, 6 Feb 89 11:37:49 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 6 Feb 89 11:46:23 EST
Received: by verdi.think.com; Mon, 6 Feb 89 11:45:54 EST
Date: Mon, 6 Feb 89 11:45:54 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902061645.AA27985@verdi.think.com>
To: masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu, maida@ibm.com
In-Reply-To: masinter.pa@xerox.com's message of 3 Feb 89 22:55 PST <890203-225602-2835@Xerox>
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 6)
Date: 3 Feb 89 22:55 PST
From: masinter.pa@xerox.com
One reason to send it out to X3J13 is to arbitrate on our notes. I notice
that Moon's notes say "Accepted with amendment that CLOSE of a closed
stream returns NIL".
Mary (or anyone else): do you have a record of the amendment & vote on
issue CLOSED-STREAM-OPERATIONS?
For what it is worth, my notes say "amended that CLOSE of a closed
stream return NIL."
--Guy
∂06-Feb-89 0902 CL-Cleanup-mailer Re: Issue: CLOSED-STREAM-OPERATIONS (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Feb 89 09:02:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534092; Mon 6-Feb-89 11:57:44 EST
Date: Mon, 6 Feb 89 11:58 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: CLOSED-STREAM-OPERATIONS (Version 6)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, maida@ibm.com
In-Reply-To: <890203-225602-2835@Xerox>
Message-ID: <19890206165817.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 3 Feb 89 22:55 PST
From: masinter.pa@Xerox.COM
One reason to send it out to X3J13 is to arbitrate on our notes. I notice
that Moon's notes say "Accepted with amendment that CLOSE of a closed
stream returns NIL".
I rechecked my original handwritten notes and they really do say that CLOSE
of a closed stream returns NIL rather than T. However, I don't care at all
which it returns, and it may be that I wrote down the amendment incorrectly.
Mary (or anyone else): do you have a record of the amendment & vote on
issue CLOSED-STREAM-OPERATIONS?
∂06-Feb-89 0937 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Feb 89 09:37:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534098; Mon 6-Feb-89 12:01:45 EST
Date: Mon, 6 Feb 89 12:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND (Version 2)
To: Guy Steele <gls@Think.COM>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8902061640.AA27962@verdi.think.com>
Message-ID: <19890206170212.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 6 Feb 89 11:40:11 EST
From: Guy Steele <gls@Think.COM>
Date: Fri, 3 Feb 89 18:11 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
...
In fact the feature that I really prefer is the one that provides an
automatic DECLARE IGNORE for any variable that is named IGNORE and is
not referenced. For some reason I was hesitant to suggest that; I think
I was being stupid.
Presumably you want the additional special treatment that such
variables named IGNORE are exempt from the prohibition on the same
variable appearing twice in a lambda-list.
Right.
∂06-Feb-89 1017 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Feb 89 10:17:29 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534168; Mon 6-Feb-89 13:11:33 EST
Date: Mon, 6 Feb 89 13:11 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 6)
To: Masinter.PA@Xerox.COM, gls@Think.COM
cc: cl-cleanup@sail.stanford.edu, maida@ibm.com
In-Reply-To: <8902061645.AA27985@verdi.think.com>
Message-ID: <890206131107.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Mon, 6 Feb 89 11:45:54 EST
From: Guy Steele <gls@Think.COM>
Date: 3 Feb 89 22:55 PST
From: masinter.pa@xerox.com
One reason to send it out to X3J13 is to arbitrate on our notes. I notice
that Moon's notes say "Accepted with amendment that CLOSE of a closed
stream returns NIL".
Mary (or anyone else): do you have a record of the amendment & vote on
issue CLOSED-STREAM-OPERATIONS?
For what it is worth, my notes say "amended that CLOSE of a closed
stream return NIL."
--Guy
Personally, I think this is -awful-. I think one ought not be able to depend
on the result in this case because implementations might reasonably differ
about whether the first CLOSE really closed the stream. As such,
(LIST (CLOSE *TERMINAL-IO*) (CLOSE *TERMINAL-IO*))
might reasonably return (T T) or (T NIL), for example, depending on whether
the implementation represents the concept of `open-ness' for all streams.
The same is true for string streams.
The issue is even weirder for composite (eg, broadcast) streams where some
streams are initially open and others are not, since I think we have no
clear theory of whether such a stream is opened or closed.
I strongly suggest we consider reverting this decision in favor of either
the proposal as drafted, or some decision which is consistent with the model
I've cited above, or else that we bundle this stuff in with the issue which
is discussing the OPEN-STREAM-P operation since the issues are intimately
related. It's my understanding that that issue is now called
INPUT-STREAM-P-CLOSED and that there is no proposal written. Please correct
me if that's not so.
∂06-Feb-89 1150 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 2)
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 6 Feb 89 11:50:42 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
id AA25465; Mon, 6 Feb 89 11:25:49 -0800
Received: from frisky by franz (3.2/3.14)
id AA19171; Mon, 6 Feb 89 10:32:26 PST
Received: by frisky (3.2/3.14)
id AA00477; Mon, 6 Feb 89 10:29:42 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8902061829.AA00477@frisky>
To: David A. Moon <franz!akbar!franz!ucbarpa!STONY-BROOK.SCRC.Symbolics.COM!Moon>
Cc: Guy Steele <franz!Think.COM!gls>, franz!STONY-BROOK.SCRC.Symbolics.COM!KMP,
franz!SAIL.STANFORD.EDU!CL-Cleanup
Subject: Re: Issue: DESTRUCTURING-BIND (Version 2)
In-Reply-To: Your message of Mon, 06 Feb 89 12:02:00 EST.
<19890206170212.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 06 Feb 89 10:29:41 PST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
In fact the feature that I really prefer is the one that provides an
automatic DECLARE IGNORE for any variable that is named IGNORE and is
not referenced.
You are kidding ... right?
If you aren't then I'd like to tack on an amendment that
symbols beginning with the letters 'i' through 'n' are declared
integer and all other symbols are declared float.
Seriously, I think that what you want is the 'ignore-if-unused'
declaration we added which permits the variable to be used, but if it
isn't there are no complaints. It is very useful in macros.
∂06-Feb-89 1213 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Feb 89 12:13:23 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534287; Mon 6-Feb-89 15:10:43 EST
Date: Mon, 6 Feb 89 15:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DESTRUCTURING-BIND (Version 2)
To: John Foderaro <franz!frisky!jkf@ucbarpa.Berkeley.EDU>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8902061829.AA00477@frisky>
Message-ID: <19890206201122.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 06 Feb 89 10:29:41 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
In fact the feature that I really prefer is the one that provides an
automatic DECLARE IGNORE for any variable that is named IGNORE and is
not referenced.
You are kidding ... right?
I am not.
If you aren't then I'd like to tack on an amendment that
symbols beginning with the letters 'i' through 'n' are declared
integer and all other symbols are declared float.
That feature of Fortran is in fact a fine feature, in its place,
that has done a lot of good for a lot of people. I suppose I would
knock it if I were you, but I would not knock it if I were me.
Seriously, I think that what you want is the 'ignore-if-unused'
declaration we added which permits the variable to be used, but if it
isn't there are no complaints. It is very useful in macros.
That's an entirely different issue. The whole point of treating the
variable IGNORE specially is to avoid having to write a declaration.
If one must write a declaration, I see no advantage to the user in
having to use a longer declaration name than the existing IGNORE
declaration.
Your proposal is something different, to disable the complaint about
unused variables without causing a complaint if the variable is used.
That is indeed something people often do. In most systems it works
to write (PROGN var1 var2 var3 body...) in the macro expansion to
make var1, var2, var3 look like they are used, so no new declaration
is required for this. I don't know right now whether Common Lisp
requires this to work in all implementations, or whether the unused
variable warning is permitted to be issued whenever the compiler can
deduce that the value of the variable does not affect the result and
side effects of the computation.
∂06-Feb-89 1251 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Feb 89 12:51:03 PST
Received: from pitney-bowes ([192.9.200.50]) by heavens-gate.lucid.com id AA01494g; Mon, 6 Feb 89 12:45:25 PST
Received: by pitney-bowes id AA17605g; Mon, 6 Feb 89 12:44:10 PST
Date: Mon, 6 Feb 89 12:44:10 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8902062044.AA17605@pitney-bowes>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: franz!frisky!jkf@ucbarpa.Berkeley.EDU, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Mon, 6 Feb 89 15:11 EST <19890206201122.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND (Version 2)
Not to detract from the main point (which I endorse), doesn't
(PROCLAIM '(IGNORE IGNORE)) have most of the desired effect in
the current language?
I think treating IGNORE specially is desirable since I see no
comparable trick to allow duplicate entries in a lambda-list.
(Without a standard, the trick above has the minor danger of
"capturing" a lamentable use of IGNORE as a normal variable, but
since you presumably would get a compiler warning, it's not an
insidious problem.)
(I suppose one could also introduce an &IGNORE lambda key word, but
the thought makes me vaguely uncomfortable.)
jlm
∂06-Feb-89 1302 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 6 Feb 89 13:01:17 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06968; 6 Feb 89 18:07 GMT
Date: Mon, 6 Feb 89 18:25:20 GMT
Message-Id: <17283.8902061825@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue PROCLAIM-LEXICAL
To: Gail Zacharias <gz%spt.entity.com@NSS.Cs.Ucl.AC.UK>,
cl-cleanup@sail.stanford.edu
In-Reply-To: Gail Zacharias's message of 5 Feb 89 18:09:14 EST (Sun)
> There seem to be three somewhat separate extensions being considered in
> this proposal.
I agree that the first two issues you identify should not be
particularly controversial. However, the existence of a lexical
declaration more or less implies that there is a corresponding
proclamation, so I think we should try to give that proclamation a
reasonable meaning and separate the proposals only if that proves too
difficult.
> Finally there is the question of a declaration/proclamation which
> applies to free variable references (i.e. not referring to a lexical
> binding), which in the current proposal introduces LG lookup allowing
> you to "close over" global values of variables. This is a new a new
> concept to Common Lisp, and is clearly controversial.
It may be misleading to think of it as "closing over". The LG
proposal has only one global environment, and closures would not
need to contain any new information.
One of the problems this proposal tries to address is that in
Common Lisp it's difficult to have a global variable whose name
can also be used as a normal (lexical) variable. Since SPECIAL
proclamations affect all bindings involving the name so proclaimed
(and not just free references), a SPECIAL proclamation, or a DEFVAR,
prevents the name from being used as a non-special variable.
So how do I get a global variable of the sort that almost all
programming languages have? I could try just setting its value,
avoiding DEFVAR and the like. But then many compilers complain
about free references. I don't suppose any of them actually go
so far as to proclaim the name special, but some Lisps certainly
did do that in the past.
The LG proposal attempts to solve this problem, plus the two
other cases you mentioned, in a consistent way. I think the
explanation in terms of L, G, and D environments is fairly
clear and easy to understand, although I'm not entirely
happy with the emphasis on "searching" the environments.
I'd prefer a more static description, if possible.
So far, the alternative proposals handle fewer cases (the GLOBAL
proclamation) or are less consistent (e.g., you can override a SPECIAL
proclamation by using a LEXICAL declarations on a binding but can't
override a LEXICAL proclamation by using a SPECIAL declaration).
I would be wary of adopting a less consistent proposal, because it
would be harder to explain, understand, and use. GLOBAL seems to me
too much of a special case and seems more appropriate to a Lisp that
emphasises dynamic binding (such as InterLisp) than to one that
encourages the use of static scoping. A third possibility, changing
SPECIAL proclamations so that they do not affect bindings, is likely
to die on the grounds of incompatibility.
So that leaves LG, which is still the alternative I favor.
∂06-Feb-89 1316 CL-Cleanup-mailer issue SYMBOL-MACROLET-SEMANTICS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Feb 89 13:16:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534374; Mon 6-Feb-89 16:13:53 EST
Date: Mon, 6 Feb 89 16:14 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SYMBOL-MACROLET-SEMANTICS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8902062105.AA00450@defun.utah.edu>
Message-ID: <19890206211426.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 6 Feb 89 14:05:52 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
This proposal, which passed at the January meeting, contains the
phrase: "Specify that the expansion of a symbol macro IS subject to
further macro expansion in the same lexical environment as the symbol
macro invocation." Just to clarify this, does this mean that the
second example from p 2-81 of 88-002R is now incorrect?
Yes.
∂06-Feb-89 1307 Common-Lisp-Object-System-mailer issue SYMBOL-MACROLET-SEMANTICS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 6 Feb 89 13:07:28 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA20453; Mon, 6 Feb 89 14:05:56 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA00450; Mon, 6 Feb 89 14:05:54 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902062105.AA00450@defun.utah.edu>
Date: Mon, 6 Feb 89 14:05:52 MST
Subject: issue SYMBOL-MACROLET-SEMANTICS
To: cl-cleanup@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
This proposal, which passed at the January meeting, contains the
phrase: "Specify that the expansion of a symbol macro IS subject to
further macro expansion in the same lexical environment as the symbol
macro invocation." Just to clarify this, does this mean that the
second example from p 2-81 of 88-002R is now incorrect?
-Sandra
-------
∂06-Feb-89 1354 CL-Cleanup-mailer Issue: IGNORE-VARIABLE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Feb 89 13:53:55 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534454; Mon 6-Feb-89 16:51:58 EST
Date: Mon, 6 Feb 89 16:51 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IGNORE-VARIABLE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890206165129.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was already being discussed under DESTRUCTURING-BIND. I'm
spawning a new issue name to help partition/focus the discussion.
-----
Issue: IGNORE-VARIABLE
Forum: Cleanup
References: IGNORE declaration (p160)
Category: CHANGE
Edit history: 06-Feb-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Many users of Symbolics Common Lisp (under Symbolics Genera) have grown
used to the variable named `IGNORE' receiving special treatment and have
complained that Common Lisp does not offer the same `feature.'
Proposal (IGNORE-VARIABLE:SPECIAL-TREATMENT):
1. Define that the variable IGNORE (in the LISP package only) is always
implicitly ignored. It is an error to use the variable IGNORE.
A declaration of (IGNORE IGNORE) is permitted, but redundant.
2. Permit the variable IGNORE (or any variable declared ignored with the
IGNORE declaration) to be a duplicated variable in a binding list.
Rationale:
1. Greater syntactic conciseness.
This is effectively current practice in some implementations.
2. If only one variable is going to be dignified in this way, it must
be possible to repeat it. If it makes sense to repeat IGNORE, it makes
sense to repeat any name declared IGNORE.
Test Case:
CLtL Proposed
#1: (DEFUN FOO (IGNORE) T) may warn ok
#2: (DEFUN FOO (IGNORE) IGNORE) ok is error
#3: (DEFUN FOO (IGNORE IGNORE) T) is error ok
#4: (DEFUN FOO (IGNORE IGNORE) IGNORE) is error is error
#5: (DEFUN FOO (X X) (DECLARE (IGNORE X)) T) is error ok
#6: (DEFUN FOO (X X) (DECLARE (IGNORE X)) X) is error is error
Current Practice:
Symbolics Genera currently treats all variables with the name "IGNORE"
(regardless of package) as ignored variables and complains if you try
to use them. It provides no way to turn off the `feature.'
Symbolics Cloe does not special-case variables named "IGNORE".
Cost to Implementors:
Small.
Cost to Users:
Although the change is technically incompatible, very few programs would
be likely to require change, since a name like IGNORE is unlikely to have
been used for anything other than an ignored variable.
Cost of Non-Adoption:
Some programs would be clumsier to write.
Benefits:
Less verbose code in some cases.
Existing code in some dialects would not require translation.
Aesthetics:
At first brush, some might argue that this makes a bad special case in
the treatment of symbols as variables. However, on closer inspection,
it's clear that the language already treats some symbols magically:
- Symbols on the keyword package are treated specially with respect
to their values.
- Symbols like *PRINT-LEVEL*, etc. have pre-defined special meanings
and cannot be bound without knowing their conventions.
- Symbols like NIL and MOST-POSITIVE-FIXNUM have pre-defined values
and cannot be bound at all.
The thing which makes these changes palatable is that none of them is
based on the symbol's name. As such, anyone unhappy with this treatment
can simply make a new package that shadows the symbol and the symbol will
be treated normally if that is what is desired.
Discussion:
When translating Macsyma from Zetalisp to Common Lisp a few years ago,
the use of Maclisp/LispM-style IGNORE was so pervasive that Pitman
ultimately just did (PROCLAIM '(SPECIAL IGNORE)) to muffle all the
would-be warnings. Except for the situation of duplicate variable names,
this is a totally portable solution, but it is -not- efficient.
Some people have suggested that (PROCLAIM '(IGNORE IGNORE)) should
work, but others argue that PROCLAIM should not, in general, be assumed
to affect lexical references.
Moon and Pitman mildly support option SPECIAL-TREATMENT.
Symbolics Common Lisp users have often expressed a desire to see this
feature in portable Common Lisp.
Some Symbolics users have complained specifically about the
incompatibility between Symbolics Genera and Symbolics Cloe in their
treatment of the variable IGNORE. Although Cloe has CLtL to fall back
on for justification, Cloe is invariably seen as the "bad guy" in their
reports because it stubbornly keeps them from getting the functionality
they want on the basis of what to them seems an irrelevant religious
or philosophical concern.
Some people might want to see a symmetric treatment of an ignored
variable in SETQ and MULTIPLE-VALUE-SETQ.
Maclisp used to permit NIL to denote an ignored variable. In general
this worked out well. The disadvantages to using NIL over using
IGNORE are:
- The common kind of macroexpansion error where NIL is substituted
for a useful value is harder to detect.
- There would be a potential conflict between the any meaning for NIL
in its `proper role' at the end of a dotted list and any opposing
meaning that a destructuring operation (eg, DEFMACRO, LOOP,
DESTRUCTURING-BIND) might want to assign to a dotted variable in
that position.
Note well: Experience with Symbolics Genera shows that special case
treatment based only on the name -- or some substring thereof -- and
not also on the package is a bad idea because there is no way to get
away from the feature if you don't like it. It is therefore an important
aspect of this proposal that only LISP:IGNORE is affected, and that an
EQ-test (and not a substring comparison) is the criterion for
identifying this magic variable.
∂06-Feb-89 1419 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 2)
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 6 Feb 89 14:19:35 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
id AA29389; Mon, 6 Feb 89 14:04:19 -0800
Received: from frisky by franz (3.2/3.14)
id AA19637; Mon, 6 Feb 89 13:30:40 PST
Received: by frisky (3.2/3.14)
id AA00873; Mon, 6 Feb 89 13:27:55 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8902062127.AA00873@frisky>
To: David A. Moon <franz!akbar!franz!ucbarpa!STONY-BROOK.SCRC.Symbolics.COM!Moon>
Cc: franz!SAIL.STANFORD.EDU!CL-Cleanup
Subject: Re: Issue: DESTRUCTURING-BIND (Version 2)
In-Reply-To: Your message of Mon, 06 Feb 89 15:11:00 EST.
<19890206201122.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 06 Feb 89 13:27:54 PST
What I suggested and what you want are in fact not separate issues.
What you said you want is:
the feature that I really prefer is the one that provides an
automatic DECLARE IGNORE for any variable that is named IGNORE and is
not referenced.
In other words, what you want is a new type of declaration that a variable
should be '(declare (ignore ..))'d if it isn't used. This is reasonable
thing to ask for. You further want to restrict that to the single
symbol named 'ignore'. What is the point in adding something
if you then go and restrict it to one symbol? Where is the leverage?
If one must write a declaration, I see no advantage to the user in
having to use a longer declaration name than the existing IGNORE
declaration.
The point is that what you are asking for is different than just
automatically putting in a (declare (ignore ignore)) after every
binding of ignore. You are asking for 'ignore-if-unused' not 'ignore'
(most compilers (I assume) will complain if a variable declared ignored is
actually used).
In most systems it works
to write (PROGN var1 var2 var3 body...) in the macro expansion to
make var1, var2, var3 look like they are used, so no new declaration
is required for this.
Maybe it is just me but I consider this practice to be vile. I certainly
hope that it is legitimate for a compiler to complain if the only use
of a variable is in a place where its value isn't used.
I would consider the adoption of this 'auto-ignore' proposal as
a little wart on the language that encourages bad programming style
(i.e. rather than use a meaningful variable name and then declare
it ignored, one would be encourage to be lazy and just use 'ignore').
As we are all aware, many more man-hours are spent reading
and modifying a piece of code than are spent typing it in, so
extra time spent while typing it in really counts.
∂06-Feb-89 1638 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Feb 89 16:38:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534599; Mon 6-Feb-89 19:35:41 EST
Date: Mon, 6 Feb 89 19:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DESTRUCTURING-BIND (Version 2)
To: John Foderaro <franz!frisky!jkf@ucbarpa.Berkeley.EDU>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8902062127.AA00873@frisky>
Supersedes: <19890206231007.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890207003619.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 06 Feb 89 13:27:54 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
What I suggested and what you want are in fact not separate issues.
What you said you want is:
the feature that I really prefer is the one that provides an
automatic DECLARE IGNORE for any variable that is named IGNORE and is
not referenced.
In other words, what you want is a new type of declaration that a variable
should be '(declare (ignore ..))'d if it isn't used. This is reasonable
thing to ask for. You further want to restrict that to the single
symbol named 'ignore'. What is the point in adding something
if you then go and restrict it to one symbol? Where is the leverage?
I understand your point, but I don't see it that way. To me, asking for
a way to create user-defined synonyms for IGNORE is like asking for a
way to create user-defined synonyms for &REST. It would be more general
and flexible, but it doesn't seem necessary nor very useful.
If one must write a declaration, I see no advantage to the user in
having to use a longer declaration name than the existing IGNORE
declaration.
The point is that what you are asking for is different than just
automatically putting in a (declare (ignore ignore)) after every
binding of ignore.
No it's not.
You are asking for 'ignore-if-unused' not 'ignore'
(most compilers (I assume) will complain if a variable declared ignored is
actually used).
No, I was asking for the equivalent of the IGNORE declaration. Unfortunately
I expressed myself poorly, so I can see how you thought I was asking for
something different. I'm sorry about that.
In most systems it works
to write (PROGN var1 var2 var3 body...) in the macro expansion to
make var1, var2, var3 look like they are used, so no new declaration
is required for this.
Maybe it is just me but I consider this practice to be vile. I certainly
hope that it is legitimate for a compiler to complain if the only use
of a variable is in a place where its value isn't used.
I would consider the adoption of this 'auto-ignore' proposal as
a little wart on the language that encourages bad programming style
(i.e. rather than use a meaningful variable name and then declare
it ignored, one would be encourage to be lazy and just use 'ignore').
As we are all aware, many more man-hours are spent reading
and modifying a piece of code than are spent typing it in, so
extra time spent while typing it in really counts.
Conciseness saves reading time also.
∂07-Feb-89 0819 CL-Windows-mailer I/O generic functions
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Feb 89 08:19:17 PST
Received: by ti.com id AA26003; Tue, 7 Feb 89 10:18:11 CST
Received: from Kelvin by tilde id AA12256; Tue, 7 Feb 89 10:04:42 CST
Message-Id: <2811859381-15005799@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 7 Feb 89 10:03:01 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Cleanup@SAIL.Stanford.edu
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com
Subject: I/O generic functions
It would be nice if the Common Lisp input and output functions could be
defined in terms of primitives which are generic functions so that users
would have a portable way to create their own streams by defining classes
and methods and have those streams be acceptable to the standard I/O
functions. This would be especially valuable for supporting the
development of window systems for Common Lisp.
It may be too late to include this in the standard, but it would be useful
to at least establish some common practice guidelines to avoid unnecessary
incompatibilities between implementations that will want to do something
like this anyway. In order to get some discussion started, following is a
preliminary outline showing what might be done.
Shown below are a few primitive generic functions which would need to have
methods defined for each stream class, and a few more which the user could
either define himself, or use a default method provided by an included
class. [This does not yet include non-character streams.] Finally, it
shows how the I/O functions of CLtL could be implemented using these
generic functions. Note that the Common Lisp I/O functions themselves
cannot be made into generic functions because in nearly every case the
stream argument is optional and thus can't be specialized. Note also that
the existing generic function PRINT-OBJECT is a higher-level operation
since even when the first argument is just a character or string, it still
needs to format the output in accordance with *PRINT-ESCAPE*.
;;;; Implementation of Common Lisp I/O routines using generic functions
;;; Generic functions for primitive input operations that must be defined for each stream.
(defgeneric STREAM-READ-CHAR (stream &optional eof-error-p eof-value))
(defgeneric STREAM-UNREAD-CHAR (stream character))
(defgeneric STREAM-LISTEN (stream))
;;; Other input operations which can be defaulted by including the following class.
(defclass DEFAULT-INPUT-STREAM (stream) ())
(defgeneric STREAM-READ-CHAR-NO-HANG (stream &optional eof-error-p eof-value)
(:method ((stream default-input-stream) &optional eof-error-p eof-value)
(stream-read-char stream eof-error-p eof-value)))
(defgeneric STREAM-PEEK-CHAR (stream &optional eof-error-p eof-value)
(:method ((stream default-input-stream) &optional (eof-error-p t) eof-value)
(let ((character (stream-read-char stream eof-error-p eof-value)))
(unless (eql character eof-value)
(stream-unread-char stream character))
character)))
(defgeneric STREAM-READ-LINE (stream &optional eof-error-p eof-value)
(:method ((stream default-input-stream) &optional eof-error-p eof-value)
(let ((line (make-array 60 :element-type 'string-char :fill-pointer 0)))
(loop (let ((character (stream-read-char stream eof-error-p eof-value)))
(if (eql character eof-value)
(return (values line eof-value))
(if (eql character #\newline)
(return (values line nil))
(vector-push-extend character line))))))))
(defgeneric STREAM-CLEAR-INPUT (stream)
(:method ((stream default-input-stream)) nil))
(defgeneric STREAM-CLOSE (stream))
(defmethod STREAM-CLOSE ((stream default-input-stream)) nil) ; or is it T?
;;; Generic functions for primitive output operations that must be defined for each stream.
(defgeneric STREAM-WRITE-CHAR (stream character))
(defgeneric STREAM-START-LINE-P (stream)) ; returns true if positioned at beginning of line.
(defgeneric STREAM-LINE-COLUMN (stream)) ; returns current column number if meaningful, else nil
;;; Other output operations which can be defaulted by including the following class.
(defclass DEFAULT-OUTPUT-STREAM (stream) ())
(defgeneric STREAM-WRITE-STRING (stream string &optional start end)
(:method ((stream default-output-stream) string &optional (start 0) end)
(let ((limit (or end (length string))))
(do ((i start (1+ i)))
((< i limit))
(stream-write-char stream (char string i))))
string))
(defgeneric STREAM-TERPRI (stream)
(:method ((stream default-output-stream))
(stream-write-char stream #\newline)
nil))
(defgeneric STREAM-FRESH-LINE (stream)
(:method ((stream default-output-stream))
(if (stream-start-line-p stream)
nil
(progn (stream-terpri stream) t))))
(defgeneric STREAM-FINISH-OUTPUT (stream)
(:method ((stream default-output-stream)) nil))
(defgeneric STREAM-FORCE-OUTPUT (stream)
(:method ((stream default-output-stream)) nil))
(defgeneric STREAM-CLEAR-OUTPUT (stream)
(:method ((stream default-output-stream)) nil))
;; useful for pprint and format ~T
(defgeneric STREAM-ADVANCE-TO-COLUMN (stream column)
(:method ((stream default-output-stream) column)
(let ((current (stream-line-column stream)))
(unless (null current)
(dotimes (i (- current column))
(stream-write-char stream #\space))
t))))
(defmethod STREAM-CLOSE ((stream default-output-stream)) nil)
;;; Internal helper functions [not intended to be standardized]
(proclaim '(inline decode-read-arg))
(defun decode-read-arg (arg)
(cond ((null arg) *standard-input*)
((eq arg t) *terminal-io*)
(t arg)))
(proclaim '(inline decode-print-arg))
(defun decode-print-arg (arg)
(cond ((null arg) *standard-output*)
((eq arg t) *terminal-io*)
(t arg)))
;;; Common Lisp query functions
(defgeneric INPUT-STREAM-P (stream)
(:method ((stream default-input-stream)) t)
(:method ((stream default-output-stream)) nil))
(defgeneric OUTPUT-STREAM-P (stream)
(:method ((stream default-output-stream)) t)
(:method ((stream default-input-stream)) nil))
(defgeneric STREAM-ELEMENT-TYPE (stream)
(:method ((stream default-output-stream)) 'character)
(:method ((stream default-input-stream)) 'character))
;;; Common Lisp input functions
(defun READ-CHAR (&optional input-stream (eof-errorp t) eof-value recursive-p)
(declare (ignore recursive-p)) ; This appears to have been a mistake in CLtL.
(stream-read-char (decode-read-arg input-stream) eof-errorp eof-value))
(defun PEEK-CHAR (&optional peek-type input-stream (eof-errorp t) eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(if (null peek-type)
(stream-peek-char stream eof-errorp eof-value)
...)))
(defun UNREAD-CHAR (character &optional input-stream)
(stream-unread-char (decode-read-arg input-stream) character))
(defun LISTEN (&optional input-stream)
(stream-listen (decode-read-arg input-stream)))
(defun READ-LINE (&optional input-stream (eof-error-p t) eof-value recursive-p)
(declare (ignore recursive-p))
(stream-read-line (decode-read-arg input-stream) eof-error-p eof-value))
(defun CLEAR-INPUT (&optional input-stream)
(stream-clear-input (decode-read-arg input-stream)))
(defun READ-CHAR-NO-HANG (&optional input-stream (eof-errorp t) eof-value recursive-p)
(declare (ignore recursive-p))
(stream-read-char-no-hang (decode-read-arg input-stream) eof-errorp eof-value))
;;; Common Lisp output functions
(defun WRITE-CHAR (character &optional output-stream)
(stream-write-char (decode-print-arg output-stream) character))
(defun FRESH-LINE (&optional output-stream)
(stream-fresh-line (decode-print-arg output-stream)))
(defun WRITE-STRING (string &optional output-stream &key (start 0) end)
(stream-write-string (decode-print-arg output-stream) string start end))
(defun WRITE-LINE (string &optional output-stream &key (start 0) end)
(let ((stream (decode-print-arg output-stream)))
(stream-write-string stream string start end)
(stream-terpri stream)
string))
(defun FORCE-OUTPUT (&optional stream)
(stream-force-output (decode-print-arg stream)))
(defun FINISH-OUTPUT (&optional stream)
(stream-finish-output (decode-print-arg stream)))
(defun CLEAR-OUTPUT (&optional stream)
(stream-clear-output (decode-print-arg stream)))
∂07-Feb-89 1016 Common-Lisp-Object-System-mailer Re: I/O generic functions
Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 7 Feb 89 10:15:49 PST
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Tue, 7 Feb 89 10:14:20 pst
Received: from loopback by hplwhh.HPL.HP.COM; Tue, 7 Feb 89 10:13:10 pst
Full-Name: Warren Harris
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com,
CL-Cleanup@SAIL.Stanford.edu
Subject: Re: I/O generic functions
In-Reply-To: Your message of "Tue, 07 Feb 89 10:03:01 CST."
<2811859381-15005799@Kelvin>
Date: Tue, 07 Feb 89 10:13:06 PST
Message-Id: <26670.602878386@hplwhh>
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
I just wanted to point out that there is an entire section of Sonya Keene's
book "Object Oriented Programming in Common Lisp" dedicated to an
implementation of streams as objects. Perhaps this implementation would be
a good starting point for a formal proposal on generic i/o routines. Can
anyone summarize what might be missing in a "real" implementation?
Warren
∂07-Feb-89 1033 Common-Lisp-Object-System-mailer Re: I/O generic functions
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Feb 89 10:33:15 PST
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534937; Tue 7-Feb-89 13:29:52 EST
Date: Tue, 7 Feb 89 13:28 EST
From: Sonya Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: I/O generic functions
To: harris%hplwhh@hplabs.hp.com
cc: Gray@DSG.csc.ti.com, Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com, CL-Cleanup@SAIL.Stanford.edu
In-Reply-To: <26670.602878386@hplwhh>
Message-ID: <19890207182849.1.SKEENE@JUNCO.SCRC.Symbolics.COM>
Date: Tue, 07 Feb 89 10:13:06 PST
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
I just wanted to point out that there is an entire section of Sonya Keene's
book "Object Oriented Programming in Common Lisp" dedicated to an
implementation of streams as objects. Perhaps this implementation would be
a good starting point for a formal proposal on generic i/o routines. Can
anyone summarize what might be missing in a "real" implementation?
Warren
I'd like to recommend against this idea! My goals in developing that
example for my book were very different from your goals in designing a
real stream implementation. I wanted to keep the example as simple as
possible, while illustrating a lot of the sharing that can happen when
streams are done in an object-oriented way. My main interest was not
in doing streams the right way, but just to find something that could
illustrate good modularity and inheritance.
I agree that streams are ripe for an object-oriented design, but your
design should probably start from scratch. Actually, there are some
object-oriented streams implementations out there (Symbolics has one,
and there must be others), and you could look into those as a starting
point.
Sonya
∂07-Feb-89 1241 CL-Cleanup-mailer New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN, or Hokey-Pokey-ADJUST-ARRAY
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Feb 89 12:41:45 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02467g; Tue, 7 Feb 89 12:36:19 PST
Received: by bhopal id AA23870g; Tue, 7 Feb 89 12:38:40 PST
Date: Tue, 7 Feb 89 12:38:40 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8902072038.AA23870@bhopal>
To: gls@Think.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Guy Steele's message of Mon, 6 Feb 89 11:36:43 EST <8902061636.AA27928@verdi.think.com>
Subject: New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN, or Hokey-Pokey-ADJUST-ARRAY
[The "Hokey" comes from RPG]
I've resisted commenting on this issue, until all the ballyhoo died down.
Looking at Dick's somewhat murky amendment, and Moon's attempt to simplify
it, I would characterize those as "good faith" attempts to reduce the
degree of discrepancy between the 3600 implementation and virtually
all other Common Lisps, by *** merely retracting some of the formerly
required error checking in ADJUST-ARRAY ***.
Nevertheless, this "reduction in degree" does not address the underlying
problem, which is the portabililty of the type SIMPLE-ARRAY. Appallingly,
I see that many readers of this mailing list actually believe that the
proposal is to retract the portable type SIMPLE-ARRAY, and leave it in as
murky a state as FIXNUM formerly was. This is the disaster which I have
so vehemently opposed. Unfortunately, your "new proposal" fosters this
confusion, in the following explanatory phrases:
In implementations of kind (1), a declaration that an array is simple
(using the SIMPLE-ARRAY, SIMPLE-VECTOR, SIMPLE-STRING, or SIMPLE-BIT-VECTOR
type specifier) may be taken literally: it is a guarantee that the array
in question will be, among other things, not adjustable. The compiler in
such an implementation may rely on this declaration to produce good
compiled code.
In implementations of kinds (2) and (3), a declaration that an array
is simple is understood a little bit differently: it constitutes a
guarantee by the user that he made a good-faith effort to create a
. . .
Postscripted to this message is a copy of the message I sent to X3J13
regarding the character proposal *** and in this message I argue very
very strongly against imbuing CL with non-portable types [I'm including
it with this note since not everyone reading cl-cleanup is on x3j13].
Your phrase "In implementations of kinds (2) and (3), [type SIMPLE-ARRAY]
is understood a little bit differently" would be a giant step backwards
in this regard.
Despite opaque, clever wordings -- and despite parliamentary legerdemain
at the Hawaii meeting -- more and more people are beginning to see the
light on this. No matter what we do to ADJUST-ARRAY, there are only
two real alternatives:
(1) 3600 Lisp (and TI Lisp?) remain technically incompatible on the
definition of SIMPLE-ARRAY -- they could choose to defend this
technicality to their customers on the grounds that it provides
a very worthwhile extension to CL, while at the same time alerting
their users to the potential for porting problems.
(2) we decide to "break" the type SIMPLE-ARRAY in some way (such as
by just removing it from the language altogether); of course,
the stock hardware implementations will do nothing of the sort
-- they will continue to use the type just as at present for the
enormous benefit it provides to "fast" compilation -- and the 1989
CL Standard will simply fail to describe this most critical and
widespread feature [i.e., the standardization process will have
broken down].
Incidentally, it's not obvious to everyone just why the definition of
SIMPLE-ARRAY found on CLtL p28 is so critical to open-coding on stock
hardware. I don't want to go into a long lecture on implementational
techniques now, but at the Hawaii meeting I spoke with three other
compiler writers for stock hardware, and we all seem (independently)
to have come up with the same techniques. We all stand firmly behind
the current dichotomy between SIMPLE-ARRAY and (non-simple) ARRAY,
which excludes adjustability from "simpleness"; the matter is similar
to the use of "specialized storage" for various array element types.
-- JonL --
Date: Thu, 2 Feb 89 13:04:21 PST
From: Jon L White <jonl>
In-Reply-To: David A. Moon's message of Tue, 31 Jan 89 16:53 EST
Subject: Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
re: I'm afraid I don't understand your comment. What's inadequately
specified about SIMPLE-BASE-STRING?
Sorry, I wasn't clear enough here. The phrase used was "wishy-washy",
and it didn't mean that the specification was unclear or something;
rather, it called in question the enforcement of the specification. As
I understand it, it's entirely permissible for one implementation to
merge SIMPLE-BASE-STRING and SIMPLE-GENERAL-STRING into one type,
whereas another may make them type-disjoint.
This is a problem not specific to SIMPLE-BASE-STRING etc, but also applies
to any "wishy-washyness" about the disjointedness of types, where
there is good reason to believe that some implementations will truly
utilize that disjointnedness. Recall my comment about the situation
with the FLOAT datatype:
Contrast this with the situation regarding the type FLOAT. Although
there are many aspects of non-portability regarding the _use_ of
floating point numbers, there is no permitted variance in the definition
of the type FLOAT. It is never permissible, for example, for one
implementation to implement the FLOAT datatype as lists of integers,
and another to implement it as some low-level primitive datatype.
Thus if a user's "declaration" (CHECK-TYPE X FLOAT) fails in one
implementation, but works in another, it is not due to an inherent
weakness in the specification of the type FLOAT.
Suppose for the moment that one implementation merges the FLOAT and CONS
datatypes by implementing FLOATs as a list of three integers (such as the
the values returned by integer-decode-float), but another implementation
makes them disjoint as "primitive" types. At first blush, one might want
to dismiss this case as simply an "efficiency" concern for the second
implementation. But consider the problems for someone developing the
following program on the first implementation and delivering it on the
second:
(defun foo (x)
(if (typep x 'float)
(sin x)
(error "Must have a float")))
(foo (list 1 0 1)) ;; knowing that (float 1.0) is ...
This is a valid program in the first implementation, because the list
(1 0 1) is a valid FLOAT in that implementation. But when moving it to
the second implementation, you get a bug. Now, implementing FLOATs as
LISTs may look artificial, but this example exactly parallels one of the
more annoying porting problems that some 3600 users have when going into
virtually any of the stock hardare implementations. See footnote below.
Recall the recent cleanup proposal to "tighten up" the definition of
FIXNUM so that its use will more frequently be portable.
Recall also the recent cleanup issue to tighten the FUNCTION type so
that it is no longer ambiguous with SYMBOL.
Recall also the CLOS need to tighten up the disjointedness of the types
found on CLtL p.31 (along with others too); 88-002R, p.1-17.
Recall the trouble we've had with the ambiguity in the alternatives
for SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, and LONG-FLOAT.
Given this long history of misguided permissiveness, and our frequent
need to "tighten things up", don't you think it would a mistake to start
out with the types SIMPLE-BASE-STRING and SIMPLE-GENERAL-STRING ambiguous?
. . .
-- JonL --
Footnote:
Actually, the FLOATs-as-LISTs example is of more than passing interest,
because if you change the names appropriately, you will see exactly
the same problem that certain users have when porting code from the 3600
implementation to *any* stock hardware implementation that does serious
open-coding of AREF. Note that the only function I've mentioned is
TYPEP -- not hokey-pokey-adjust-array or whatever; that's why all the
thousands of lines of discussion about adjust-array etc on cl-cleanup are
not germane to the real problem. Focusing on adjust-array can, at best,
emasculate some of its mandated error checking; at worst, it can confuse
some would-be heros into thinking that the type disjointedness in question
is merely a matter of semantics that can cleared up by clever wording.
Make no mistake. The disjointedness is essential to the optimization
strategies of *all* the commercial stock hardware implementations
represented at the Hawaii meeting.
∂07-Feb-89 1248 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Feb 89 12:48:21 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02482g; Tue, 7 Feb 89 12:41:45 PST
Received: by bhopal id AA23898g; Tue, 7 Feb 89 12:44:07 PST
Date: Tue, 7 Feb 89 12:44:07 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8902072044.AA23898@bhopal>
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Cc: @sail.stanford.edu:jonl@lucid.com, Moon@scrc-stony-brook.arpa,
@cs.utah.edu:sandra@defun, KMP@scrc-stony-brook.arpa,
masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Jeff Dalton's message of Thu, 2 Feb 89 15:46:17 GMT <8811.8902021546@subnode.aiai.ed.ac.uk>
Subject: issue PROCLAIM-LEXICAL
re: I think these two cases should be analogous. The only reason that
they should not be (that I can see) is that PROCLAIM is somehow
"more magic" than placing the corresponding declaration on every
binding. And if it is "more magic", I think it should not be.
Rather than reply to each of the various question you raise, maybe this
last one is the important one. Yes, a proclamation is more pervasive
than any bounded set of DECLARE's inserted into code. In particular,
the DECLAREs (of your examples) are in the same lexical scope; but
the PROCLAIM might even be in another separately-compiled file.
-- JonL --
∂07-Feb-89 1252 CL-Cleanup-mailer issue PROCLAIM-LEXICAL
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Feb 89 12:52:10 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02503g; Tue, 7 Feb 89 12:46:42 PST
Received: by bhopal id AA23943g; Tue, 7 Feb 89 12:49:04 PST
Date: Tue, 7 Feb 89 12:49:04 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8902072049.AA23943@bhopal>
To: gz@spt.entity.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Gail Zacharias's message of 5 Feb 89 18:09:14 EST (Sun) <8902051809.AA16827@spt.entity.com>
Subject: issue PROCLAIM-LEXICAL
Your suggestion to separate out the proposal parts that are purely
lexically scoped from the PROCLAIM extensions (which are not just
lexically scoped) sounds reasonable to me.
-- JonL --
∂07-Feb-89 1302 CL-Cleanup-mailer Issue: SUBTYPEP-EMPTY-NIL (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Feb 89 13:01:56 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 535083; Tue 7-Feb-89 15:59:55 EST
Date: Tue, 7 Feb 89 15:59 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890207155926.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: SUBTYPEP-EMPTY-NIL
Forum: Cleanup
References: 2.15 Overlap, Inclusion, and Disjointness of Types (p33-35),
SUBTYPEP (p72),
Category: CLARIFICATION
Edit history: 07-Feb-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
When a type description is restricted by range or enumeration, and the
restricted type turns out to be empty, is the type a subtype of NIL?
Test Cases:
#1: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) => ??
#2: (SUBTYPEP '(MEMBER) NIL) => ??
Proposal (SUBTYPEP-EMPTY-NIL:NIL-T):
Specify that empty ranges are not a subtype of NIL.
The test cases would then have to return either {NIL, T},
or {NIL, NIL}.
Rationale: The two types are different in intention.
Proposal (SUBTYPEP-EMPTY-NIL:T-T):
Specify that empty ranges are a subtype of NIL.
The test cases would then have to return either {T, T},
or {NIL, NIL}.
Rationale: The two types are not distinguishable in practice.
Proposal (SUBTYPEP-EMPTY-NIL:EXPLICITLY-VAGUE):
Explicitly acknowledge that the relationship between empty range or
enumeration types and the type named NIL is unspecified.
The test cases could then return any of {T, T}, {NIL, T},
or {NIL, NIL}.
Rationale: This is a fall-back in case no agreement is reached.
Current Practice:
For test case #1,
Symbolics Genera 7.1 returns {NIL, T}.
For test case #2,
Symbolics Genera 7.1 returns {NIL, T}.
Cost To Implementors:
There is no cost to EXPLICITLY-VAGUE.
The cost to the other options for implementations which don't already
conform is probably fairly small.
Cost To Users:
Probably most users don't depend on this. Those users who do depend on it,
can't rely on it in portable code because the spec is too vague.
Cost of Non-Adoption:
Unnecesary ambiguity.
Benefits:
Users will know what to expect.
Aesthetics:
No aesthetic impact yet identified.
Discussion:
Pitman mildly supports NIL-T. Steele mildly supports T-T.
Probably the answer is not as important as making sure implementations
agree and that users know what to expect.
∂07-Feb-89 1325 CL-Cleanup-mailer Issue: DEFSTRUCT-REDEFINITION (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Feb 89 13:25:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 FEB 89 11:23:12 PST
Date: 6 Feb 89 17:01 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFSTRUCT-REDEFINITION (Version 3)
Message-ID: <890207-112312-1669@Xerox>
Accepted, with amendment to use the word "undefined". I presume
that this meant to replace "not specified in the standard."
!
Status: Passed (as amended) Jan 89 X3J13
Issue: DEFSTRUCT-REDEFINITION
References: DEFSTRUCT (CLtL pp 305-320)
Related-issues: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Category: CLARIFICATION
Edit history: Version 1 by Skona Brittain 07/26/88
Version 2 by Larry Masinter 7-Jan-89
Version 3 by Masinter 6-Feb-89 as per Jan 89 X3J13 amendment
Problem Description:
The case of a structure type being redefined is not discussed in CLtL. Is
it legal to redefine a DEFSTRUCT? What happens to DEFSTRUCTS that :INCLUDE
the one defined. What things might be "wired in" in compiled code that
refered to the previous DEFSTRUCT?
Proposal: (DEFSTRUCT-REDEFINITION:ERROR):
Redefining a DEFSTRUCT structure is not portable. The results of doing so
are undefined.
Rationale:
DEFSTRUCT is intended as "the most efficient" structure class. DEFCLASS
allows much more flexible structures to be defined. Thus, implementations
should be free to "wire in" much of the behavior of a DEFSTRUCT into
compiled code.
The issue of redefinition should be addressed since there are always
consequences that affect use of the structures.
Current Practice:
None of KCL, Lucid, & Symbolics detect a redefinition.
Envos Medley goes to some effort to detect if a new structure is
"compatible" with the old -- e.g., slots might change names, initial
values, but, since the space allocated in an instance is determined by the
:TYPE, an incompatible set of :TYPE forms would cause old instances to be
marked "obsolete". (The TYPE-OF an old instance changes to **OBSOLETE**,
for example.)
Cost to Implementors:
This proposal attempts to be consistent with current practice.
Cost to Users:
It is doubtful that any current programs actually define structures more
than once. Thus, constraints on DEFSTRUCT redefinition primarily affect the
debugging environment.
Cost of Non-Adoption:
Confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior should be
explicitly considered an error.
Discussion:
Common implementation techniques may cause the following behavior if a
DEFSTRUCT is redefined:
If the new DEFSTRUCT is identical to the old DEFSTRUCT except for the
initialization forms for slots, previous structure objects probably can
continue to be accessed with previously compiled slot accessors. DEFSTRUCT
constructor, test functions are proclaimed INLINE, and if these have
changed, previously compiled occurrences of them may behave unpredictably.
If any change is made to the definiton of the slots (either in number,
name, or :TYPE), attempting to execute a slot accessor of the old
definition may behave unpredictably: if a slot name of the old definition
also names a slot of the new definition, any "compiled" code might use the
old definition instead.
DEFSTRUCT constructor, test functions may also be proclaimed INLINE, and
may behave unpredictably if previously compiled. In particular, a compiled
occurance of a constructor might have the previously slot initial values
"wired in".
If the new DEFSTRUCT differs from the old in any aspect other than the
initialization forms for slots, the results of attempting to access any old
instance might result in unspecified behavior. For example, if the size of
the structure became considerably shorter, an old accessor might "access
off the end" of an instance of a new object; it might signal an error or
have other unpredictable results.
Masinter supports this proposal. If users want more flexibility than
DEFSTRUCT allows, they should use DEFCLASS.
Some felt strongly that just saying it's an error to redefine a structure
but not requiring the error to be signalled will cause users to be confused
by the differing seemingly erratic behavior and code.
Programming environments are allowed, encouraged, etc. to allow such
redefinition, perhaps with warning messages. It is beyond the scope of the
language standard to define those interactions, except to note that they
are not portable.
Here's an example where reexecuting an EQUAL DEFSTRUCT might result in
different behavior:
(defvar *token-counter* 0)
(defstruct token (cookie '("unique-string")) (counter (incf
*token-counter*)))
(defvar *first-token* (make-token))
(eql (token-cookie *first-token*) (token-cookie (make-token))) => true
(defstruct token (cookie '("unique-string")) (counter (incf
*token-counter*)))
(eql (token-cookie *first-token*) (token-cookie (make-token))) => false
I.e., even though the second DEFSTRUCT is EQUAL to the first, the
structures are not EQL.
This is related to the compiler issue QUOTE-MAY-COPY, but is not the same
issue, since that proposal isn't proposing that QUOTE might copy its value
*every time* it is executed.
----- End Forwarded Messages -----
∂07-Feb-89 2005 CL-Cleanup-mailer I/O generic functions
Received: from PORSCHE.SCRC.Symbolics.COM ([128.81.41.69]) by SAIL.Stanford.EDU with TCP; 7 Feb 89 19:39:53 PST
Received: from OWL.SCRC.Symbolics.COM by PORSCHE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 230; Tue 7-Feb-89 22:03:09 EST
Date: Tue, 7 Feb 89 22:02 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: I/O generic functions
To: David N Gray <Gray@DSG.csc.ti.com>
cc: CL-Cleanup@SAIL.Stanford.edu, Common-Lisp-Object-System@SAIL.Stanford.edu,
CL-Windows@SAIL.Stanford.edu, Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com
In-Reply-To: <2811859381-15005799@Kelvin>
Message-ID: <19890208030248.1.MMCM@OWL.SCRC.Symbolics.COM>
This is the right sort of start. I have a few observations which are
not meant to be comprehensive. They might help stimulate further
careful design.
STREAM-LISTEN is actually not mandatory: you can implement it using
READ-CHAR-NO-HANG and UNREAD-CHAR.
If people are going to start defining well behaved streams, some
protocols need to be firmed up. For instance, if LISTEN is true, must
READ-CHAR-NO-HANG return a character? Or is it only that
READ-CHAR-NO-HANG returns a character or clears the LISTEN condition?
You can see the difference in the behavior of an encapsulated stream
with escape characters. In the one case, LISTEN can just do LISTEN on
the inside stream, which is presumably fast (e.g. checks some network
buffer pointers). If the buffer contains only the start of an escape
sequence, READ-CHAR-NO-HANG will still not return a character. In the
other case, LISTEN must run the entire decoding machinery right away and
unread any character it produces. The key decision is whether you want
LISTEN to be complete or efficient.
Wouldn't it be better to have just one centralized implementation of
eof-error-p eof-value handling? The internal stream methods could obey
just one protocol for returning EOF which the outer would process
independently.
∂07-Feb-89 2252 CL-Cleanup-mailer Issue: SUBTYPEP-EMPTY-NIL (Version 1)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 89 22:52:29 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA26202@EDDIE.MIT.EDU>; Wed, 8 Feb 89 01:50:36 EST
Received: by spt.entity.com (smail2.5); 8 Feb 89 01:10:18 EST (Wed)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Tue, 7 Feb 89 15:59 EST <890207155926.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
Message-Id: <8902080110.AA21055@spt.entity.com>
Date: 8 Feb 89 01:10:18 EST (Wed)
From: gz@spt.entity.com (Gail Zacharias)
This is a joke, right? You're not seriously suggesting that
(SUBTYPEP <empty set> NIL) => NIL T is anything but a bug?
∂08-Feb-89 0639 CL-Cleanup-mailer Issue: SUBTYPEP-EMPTY-NIL (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 89 06:39:47 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 535631; 8 Feb 89 09:37:44 EST
Date: Wed, 8 Feb 89 09:37 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
To: gz@spt.entity.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8902080110.AA21055@spt.entity.com>
Message-ID: <890208093740.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Sorry, but this is a serious attempt to get a clarification.
I don't see that any criterion has been advanced by CLtL for believing
NIL T is any better or worse than T T. If CLtL is clear and I've just
missed the passage, by all means cite it. Alternatively, you may have some
personal criterion which you'd like us to buy into. If you propose that
criterion and no one contests, I'll be quite happy to see the issue
turn out to resolved by a non-controversial vote.
Here's some extra data on the problem as I see it...
Btw, another pair of test cases which has occurred to me since then are:
(SUBTYPEP '(INTEGER (1.0) (#,(+ 1.0 SINGLE-FLOAT-EPSILON))) '())
(SUBTYPEP '(INTEGER (1.0) (#.(+ 1.0 SINGLE-FLOAT-EPSILON))) '())
The integer range denoted in both cases is empty. If we assume that the
compiler works by calling READ, then a compiler can in principle recognize
the first as portable code so would not want to complain about it, but he
cannot recognize the second as portable as portable. An implementator who
likes to build in lots of checking to promote portability might be bothered
by this disparity. It is this kind of issue I meant of when I referred to
programmer "intention".
Note that in recent discussions of array types, we have acknowledged
any notion of programmer intention in permitting
(SUBTYPEP '(ARRAY FIXNUM) '(ARRAY T))
and
(SUBTYPEP '(ARRAY T) '(ARRAY FIXNUM))
to both return T. We did this not because we wanted these particular
operations to return T -- since I would assume it's clear that in an
ideal world that would be undesirable -- but because it was possible
to better optimize a now-win situation by permitting this behavior in
order to achieve some other, more important, relationships. Perhaps
the same has to be true of SUBTYPEP for the new situation this issue
addresses.
∂08-Feb-89 0907 CL-Cleanup-mailer Re: Issue: IGNORE-VARIABLE (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Feb 89 09:07:10 PST
Received: by ti.com id AA01426; Wed, 8 Feb 89 11:04:59 CST
Received: from Kelvin by tilde id AA13487; Wed, 8 Feb 89 10:57:33 CST
Message-Id: <2811949017-5051752@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 8 Feb 89 10:56:57 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: IGNORE-VARIABLE (Version 1)
In-Reply-To: Msg of Mon, 6 Feb 89 16:51 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> Proposal (IGNORE-VARIABLE:SPECIAL-TREATMENT):
>
> 1. Define that the variable IGNORE (in the LISP package only) is always
> implicitly ignored. It is an error to use the variable IGNORE.
> A declaration of (IGNORE IGNORE) is permitted, but redundant.
>
> 2. Permit the variable IGNORE (or any variable declared ignored with the
> IGNORE declaration) to be a duplicated variable in a binding list.
The Explorer already supports this except for the part about permitting
multiple use of any variable declared IGNORE.
I agree that this is a convenience which is often used, but I am less
sure about whether it is good programming practice.
∂08-Feb-89 0921 CL-Cleanup-mailer Re: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Feb 89 09:20:59 PST
Received: by ti.com id AA01508; Wed, 8 Feb 89 11:19:35 CST
Received: from Kelvin by tilde id AA13765; Wed, 8 Feb 89 11:07:11 CST
Message-Id: <2811949593-5086377@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 8 Feb 89 11:06:33 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
In-Reply-To: Msg of Tue, 7 Feb 89 15:59 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> Proposal (SUBTYPEP-EMPTY-NIL:T-T):
>
> Specify that empty ranges are a subtype of NIL.
>
> The test cases would then have to return either {T, T},
> or {NIL, NIL}.
Sounds good; this seems like a reasonable interpretation of an otherwise
meaningless situation.
> Current Practice:
The Explorer currently returns {NIL, T} for #1 but {T, T} for #2,
although the latter may have been more by accident than by design.
∂08-Feb-89 1010 CL-Cleanup-mailer Re: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 89 10:10:49 PST
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 8 Feb 89 13:08:15 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: gz@spt.entity.com, CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
In-reply-to: Your message of Wed, 08 Feb 89 09:37:00 -0500.
<890208093740.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 08 Feb 89 13:07:42 EST
From: Rob.MacLachlan@WB1.CS.CMU.EDU
The NIL T proposal isn't adequate as currently presented. If an empty
numeric range or member type isn't equivalent to NIL, what is it equivalent
to. Is (integer (0) (0)) == (float (0.0) (0.0))? Is an empty member type
equivalent to an empty numeric type?
If these types are placed somewhere in the hierarchy other than at the
bottom, then we must say where. Presumably each of these new empty types
is a lower bound on some existing collection of types, and we need to say
which.
I am personally in favor of making all of these types == NIL, since it
seems simpler. This seems also to be more compatible with the "types
are sets" view stated in CLtL. All type specifiers that designate the
empty set should be equivalent.
I think that your example is pretty contrived. Regardless of the type
system, the compiler can't do much with type specifiers that are
constructed at load time. The right way to do this would be with a
DEFTYPE, which could be expanded at compile time.
Rob
∂08-Feb-89 1107 CL-Cleanup-mailer Re: Issue: IGNORE-VARIABLE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 89 11:07:42 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 535877; Wed 8-Feb-89 14:04:27 EST
Date: Wed, 8 Feb 89 14:04 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: IGNORE-VARIABLE (Version 1)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: Gray@DSG.CSC.TI.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <2811949017-5051752@Kelvin>
Message-ID: <890208140425.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 8 Feb 89 10:56:57 CST
From: David N Gray <Gray@DSG.csc.ti.com>
... I agree that this is a convenience which is often used, but I am less
sure about whether it is good programming practice. ...
One good metric of whether it is a good programming practice is whether
it ever leads to trouble. Do you ...
- have any bug reports on file from people who were caught by
it unaware and asked to have the feature removed.
- have any instances of real code that uses IGNORE where you felt
the writer's intent would have been clearer if he'd done something else?
I think most of the examples of using IGNORE that I've seen are very tasteful.
Things like (MAPCAR #'(LAMBDA (IGNORE) (GENSYM)) VARS) to construct a list
of temporary variables in a macro is ultimately more readable, I think,
than (MAPCAR #'(LAMBDA (VAR)
(DECLARE (IGNORE VAR))
VAR)
VARS)
since the latter conveys no more information in some people's coding style.
(If I call a list of vars <name>S, it means that the elements will be <name>.)
All the long form ultimately does is to force me to use up three more screen
lines because (as a matter of personal policy) I try never put multiple forms
in an implicit progn on the same line. I assert that anything that gratuitously
loses me screen lines makes the program less readable. The issue is only
whether this is a case where the loss is gratuitous.
Already you cannot choose variable names in Common Lisp with no
regard to how those names were defined. If you do, you'll trip over names
like MOST-POSITIVE-FIXNUM. (Any argument that says you'd never accidentally
choose that one must surely say you'd never choose IGNORE either.) So there's
no big deal about working around the name IGNORE simply by placing it in a list
everyone has to know about of names they shouldn't use without reading doc.
Beyond that, I claim, it's just a matter of "are you going to provide the user
what he clearly wants". The only rational counter-argument (I believe) is not
an aesthetic one because the person making that argument has no leg to stand on.
There is a somewhat rational argument that you're just tired of adding little
features that let users "get what they want" and you just want to say "tough!
i've given you a lot of things. what you're asking for is reasonable but the
cost in terms of address space or my time to implement it or whatever is too
high and i will not give it to you." This argument was used, for example,
in rejecting CONJOIN, DISJOIN, etc. Given that you acknowledge the convenience
factor, however, that argument is weakened dramatically.
As an aside, the aforementioned metric cited above -would- suffice to show why
looking at the variable's name (independent of package) is not acceptable, since
I can cite actual bugs in real programs that have come from having gensyms with
names like "IGNORE" -- due to doing (MAKE-SYMBOL (SYMBOL-NAME USER-VARIABLE)).
Flexibility to use the same name in uninterned symbols or shadowed symbols in
order to dig one's way out of the attached semantics of a particular symbol is
fundamental to the whole concept of the package system. However, within a
particular module or package, where use of the package presumably means that
it is a given that the user understands its workings, I think matters of
convenience should be catered to.
∂08-Feb-89 1112 CL-Cleanup-mailer Issue: SUBTYPEP-EMPTY-NIL (Version 1)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 89 11:12:03 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA12987@EDDIE.MIT.EDU>; Wed, 8 Feb 89 14:10:07 EST
Received: by spt.entity.com (smail2.5); 8 Feb 89 14:02:52 EST (Wed)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 8 Feb 89 09:37 EST <890208093740.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
Message-Id: <8902081402.AA21888@spt.entity.com>
Date: 8 Feb 89 14:02:52 EST (Wed)
From: gz@spt.entity.com (Gail Zacharias)
If CLtL is clear and I've just missed the passage, by all means cite it.
CLtL p72: "If a data type is viewed as the set of all objects belonging to the
type, then the TYPEP function is a set membership test, while SUBTYPEP is a
subset test."
∂08-Feb-89 1230 CL-Cleanup-mailer Issue: SUBTYPEP-EMPTY-NIL (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 89 12:30:27 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 535926; Wed 8-Feb-89 15:28:12 EST
Date: Wed, 8 Feb 89 15:28 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
To: gz@spt.entity.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8902081402.AA21888@spt.entity.com>
Message-ID: <890208152811.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 8 Feb 89 14:02:52 EST (Wed)
From: gz@spt.entity.com (Gail Zacharias)
If CLtL is clear and I've just missed the passage, by all means cite it.
CLtL p72: "If a data type is viewed as the set of all objects belonging to the
type, then the TYPEP function is a set membership test, while SUBTYPEP is a
subset test."
Hmmm. I'd missed that little paragraph up there. It does seem to support
your claim (though it still makes me a little queasy). The wording is
obviously informal since I might just as easily expect the term "subset
test" to imply something like (subtypep '(3 4 5) 'number) => t, but
later examples seem to fix that up ok. Also, whenever very informal
descriptions like this occur, I'm a bit leary of drawing too many
conclusions from them because I'm not certain that the speaker
(Steele in this case) had intended the wording to hold up under too
much heavy inferencing...
Still, if no one disagrees that this is the apparent intent (and no one but me
has spoken up so far), then I'm content to declare this issue resolved by sending
mail to Kathy identifying the issue, and asking her to resolve it by making
the point clearer [per option T-T, which permits results T T or NIL NIL] and
including the examples from the writeup. The simple presence of those examples
in the draft to be approved will make it apparent to reviewers that we believe
this to be a consequence of the wording, and that if they disagree they should
object [as they would object to anything else that they noticed to be
incongruous].
∂08-Feb-89 1251 CL-Cleanup-mailer Re: Issue: IGNORE-VARIABLE (Version 1)
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 89 12:51:46 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
id AA09770; Wed, 8 Feb 89 12:20:13 -0800
Received: from frisky by franz (3.2/3.14)
id AA02935; Wed, 8 Feb 89 11:57:26 PST
Received: by frisky (3.2/3.14)
id AA02229; Wed, 8 Feb 89 11:54:35 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8902081954.AA02229@frisky>
To: Kent M Pitman <franz!akbar!franz!ucbarpa!STONY-BROOK.SCRC.Symbolics.COM!KMP>
Cc: franz!SAIL.Stanford.EDU!CL-Cleanup
Subject: Re: Issue: IGNORE-VARIABLE (Version 1)
In-Reply-To: Your message of Wed, 08 Feb 89 14:04:00 EST.
<890208140425.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 08 Feb 89 11:54:34 PST
>> One good metric of whether it is a good programming practice is whether
>> it ever leads to trouble. Do you ...
>>
>> - have any instances of real code that uses IGNORE where you felt
>> the writer's intent would have been clearer if he'd done something else?
I'm sure that if you gave me access to source code where 'ignore' was
used, I could find plenty of examples where it shouldn't have been.
Since I don't have that access, I looked in the pcl code (not to pick
on pcl, but it was all that I had):
from 3600-low.cl:
(defun set-function-name-1 (fn new-name ignore)
(cond ((or (funcallable-instance-p fn)
(si:lexical-closure-p fn))
So set-function-name-1 takes three arguments, what is the third
argument? Suppose I want to rewrite set-function-name-1, maybe I'll
need this variable when I rewrite it.
Here is how it should be written (sure it takes more keystrokes
but it is worth it):
from coral-low.cl:
(defun set-function-name-1 (function new-name uninterned-name)
(declare (ignore uninterned-name))
(cond ((ccl::lfunp function)
from macros.cl:
(defmacro destructuring-bind (pattern form &body body)
(multiple-value-bind (ignore declares body)
(extract-declarations body)
again, the question the reader of this code has is what the first
value returned by extract-declarations?
∂08-Feb-89 1428 CL-Cleanup-mailer Re: Issue: IGNORE-VARIABLE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 89 14:28:36 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 536009; Wed 8-Feb-89 17:25:35 EST
Date: Wed, 8 Feb 89 17:25 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: IGNORE-VARIABLE (Version 1)
To: franz!frisky!jkf@ucbarpa.Berkeley.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8902081954.AA02229@frisky>
Message-ID: <890208172531.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Just because you refuse permit to a particular shorthand doesn't mean
people will write the same concept in longhand the way you want them to.
Nothing stops people from writing
(defun foo (x y ignore)
(declare (ignore ignore))
...)
People do this all the time. Sometimes they use the word IGNORE.
Sometimes they use the word IGNORED, STUFF, JUNK, HUNOZ, or whatever.
But they do it.
Also, if they were only interested in the first argument, nothing would
keep them from writing
(defun foo (x &rest more-arguments)
(declare (ignore more-arguments))
...)
I do this all the time, by the way, and I don't think
(defun foo (x &rest ignore) ...)
would be any less readable.
If someone really knows he's not going to use something, why does he
need to name it? Just because he gets his grins from wasting symbol
space or watching his code run onto the next screenful or from feeding
the printer an extra sheet of paper? I don't use the value of the
square of pi when I compute factorial and I would not consider ever
using it even if you insisted on passing it to me. Why should I be
forced to devise a name for a thing I'm sure I'm not going to use?
This problem is particularly acute for anonymous procedures where I can
often see the argument that is being passed in, what is being used, etc.
I'm saying this feature is useful and that I could use it judiciously.
You're saying this feature is not useful and that people could abuse it.
I ignore the argument that it could be abused because that's true of
most everything. We're left with an "I think it's useful; you think it's
not argument".
As a general rule of thumb, in the absence of a technical argument for
solving a dispute, when someone claims that something is useful and
someone else claims it is not, I believe the person claiming it is not
is most likely to be wrong (since for nearly everything that is useful
you can find a situation where it is not without having proved anything).
Anyway, I've made my point and plan to say no more on this unless
specifically asked to.
∂08-Feb-89 1704 CL-Cleanup-mailer Re: I/O generic functions
Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Feb 89 17:03:56 PST
Received: by ti.com id AA03252; Wed, 8 Feb 89 19:02:12 CST
Received: from Kelvin by tilde id AA26026; Wed, 8 Feb 89 18:51:42 CST
Message-Id: <2811977439-6887731@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 8 Feb 89 18:50:39 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.edu, kempf@Sun.COM, harris%hplwhh@hplabs.hp.com,
Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com
Subject: Re: I/O generic functions
In-Reply-To: Msg of Tue, 7 Feb 89 22:02 EST from Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
> STREAM-LISTEN is actually not mandatory: you can implement it using
> READ-CHAR-NO-HANG and UNREAD-CHAR.
Yes, I guess you could. I'm not sure whether that really helps anyone,
though, since a custom method for STREAM-LISTEN would always be faster.
> If people are going to start defining well behaved streams, some
> protocols need to be firmed up. For instance, if LISTEN is true, must
> READ-CHAR-NO-HANG return a character? Or is it only that
> READ-CHAR-NO-HANG returns a character or clears the LISTEN condition?
> You can see the difference in the behavior of an encapsulated stream
> with escape characters. In the one case, LISTEN can just do LISTEN on
> the inside stream, which is presumably fast (e.g. checks some network
> buffer pointers). If the buffer contains only the start of an escape
> sequence, READ-CHAR-NO-HANG will still not return a character. In the
> other case, LISTEN must run the entire decoding machinery right away and
> unread any character it produces. The key decision is whether you want
> LISTEN to be complete or efficient.
An interesting point, but I'm not sure when the eager version of LISTEN
would actually result in a noticeable hang, since the rest of the escape
sequence is going to follow very soon. Note that page 380 of CLtL says
that
On a non-interactive stream, the general rule is that LISTEN is
true except when at end-of-file.
which implies that delays getting the next physical record from disk or
the next packet from the network are not to be considered significant.
Are you thinking that a terminal user might need to press two keys in
sequence to cause one special character to be input? In that case, I
think it would be clear that you don't want LISTEN to return true until
all of the necessary keys have been pressed.
> Wouldn't it be better to have just one centralized implementation of
> eof-error-p eof-value handling? The internal stream methods could obey
> just one protocol for returning EOF which the outer would process
> independently.
Yes, that sounds like a good idea. Maybe something like the following?
(defconstant THE-EOF-FLAG <some-unique-value>)
(defgeneric STREAM-READ-CHAR (stream)
(:documentation "Returns either a character or THE-EOF-FLAG."))
(defun READ-CHAR (&optional input-stream (eof-errorp t) eof-value recursive-p)
(declare (ignore recursive-p))
(let* ((stream (decode-read-arg input-stream))
(value (stream-read-char stream)))
(if (eq value the-eof-flag)
(report-eof stream eof-errorp eof-value)
value)))
(defun report-eof (stream eof-errorp eof-value)
(if eof-errorp
(error 'end-of-file :stream stream)
eof-value))
∂08-Feb-89 2017 CL-Cleanup-mailer Issue: SUBTYPEP-EMPTY-NIL (Version 1)
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 8 Feb 89 20:17:07 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 269332; Wed 8-Feb-89 23:14:52 EST
Date: Wed, 8 Feb 89 23:14 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, gz@spt.entity.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890208093740.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890209041431.0.GSB@GANG-GANG.SCRC.Symbolics.COM>
Date: Wed, 8 Feb 89 09:37 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Sorry, but this is a serious attempt to get a clarification.
I don't see that any criterion has been advanced by CLtL for believing
NIL T is any better or worse than T T. If CLtL is clear and I've just
missed the passage, by all means cite it. Alternatively, you may have some
personal criterion which you'd like us to buy into. If you propose that
criterion and no one contests, I'll be quite happy to see the issue
turn out to resolved by a non-controversial vote.
NIL T leads to a situation of functionally equivalent forms of the "empty"
type set not being equivalent under (and (subtypep x y) (subtypep y x)).
I believe that to be a good argument for T T, whether or not CLtL even
hints that this should be the case.
∂09-Feb-89 0656 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Feb 89 06:56:53 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01831g; Thu, 9 Feb 89 06:51:15 PST
Received: by bhopal id AA05327g; Thu, 9 Feb 89 06:53:37 PST
Date: Thu, 9 Feb 89 06:53:37 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8902091453.AA05327@bhopal>
To: Gregor.pa@Xerox.COM
Cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Sun, 5 Feb 89 11:07 PST <19890205190724.0.GREGOR@SPIFF.parc.xerox.com>
Subject: Issue: CLOS-CONDITIONS (Version 3)
re: BTW, if you want a concise version of my rational for B over A its:
"The best argument for adding list function specifiers to the
language was to avoid the problems caused by automaticall
creating and interning symbols. That argument must also be
strong to eliminate automatically generated symbols from
define-condition."
Agreed. At Lucid, we have had bug reports (as well as confusion
reports?) due to the symbol-concing nature of DEFINE-CONDITION. We've
perpretated a "50%" fix, and declined to do a "90%" fix on the theory
that when conditions become classes, the need for symbol concing will be
gone. Let it be gone, even at the expense of a minor incompatibility
with "old" error syntax. [After all, this "old" error system is "brand
new" to almost all CL users; and many of those using it are aware that
the current implementations may change slightly when the final ANSI
standard is published).
-- JonL --
∂10-Feb-89 1325 CL-Cleanup-mailer re: PATHNAME-PRINT-READ, v1
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 89 13:25:26 PST
Date: Thu 9 Feb 89 11:25:54-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: re: PATHNAME-PRINT-READ, v1
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12469353749.28.IIM@ECLA.USC.EDU>
I agree with your sentiments regarding multiple file systems. We spent a lot
of time thinking about the problems involved in dealing with such situations,
and I don't know that we really got very far in solving them. To some extent
we've punted, since we are currently in a "single file system" environment.
That's changing though, and we're going to have to face up to the situation.
While I wasn't persuaded by the arguments for #H for printing hash-tables, I
think they bear more weight in the case of pathnames. I could easily be
persuaded to support printing pathnames in some standard format (though not
necessarily #P -- I agree with GSB (1/5/89) and Dan Pierson (1/6/89) that we
should be careful about chewing up # reader macros), if it could be specified
in such a way that multiple file system problems were at least solvable
(preferably solved, but that seems to be asking too much).
BTW, I don't think a Symbolics pathname of #P"host:asdf" is equivelent to
#.(parse-namestring "asdf" "host"), since the former contains a manifest host,
while the latter might not (depending on how "host" parses the string "asdf").
On rereading the top of CLtL p.415 though (manifest host must match explicit
parsing host), maybe the "right" way to print the latter is really
#.(parse-namestring "asdf" nil #.(parse-namestring <string> "host"))
<string> := namestring which specifies only the host "host", in the syntax
used by the host "host" (got that).
Bletch.
Fortunately, most of the time this can be collapsed to the former rendering in
one way or another. The case where you can't seems pretty pathological (parse
a string according to some host's parsing conventions, but it contains a
manifest host which is not only not the host used for parsing, but parses
pathnames differently from the host used for parsing).
kab
-------
∂10-Feb-89 2353 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Feb 89 23:53:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 FEB 89 23:46:28 PST
Date: 10 Feb 89 23:45 PST
From: masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
Subject: Issue: FUNCTION-COMPOSITION (Version 5)
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <890210-234628-3998@Xerox>
!
Status: Passed (as amended) Jan 89 X3J13
Forum: Cleanup
Issue: FUNCTION-COMPOSITION
References: None
Category: ADDITION
Edit history: 21-Jun-88, Version 1 by Pitman
05-Oct-88, Version 2 by Pitman
7-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter (additional comments)
10-Feb-89, Version 5 (as amended by X3J13 Jan 89)
Related-Issues: TEST-NOT-IF-NOT
Problem Description:
A number of useful functions on functions are conspicuously
absent from Common Lisp's basic set. Among them are functions
which return constant T, constant NIL, and functions which
combine functions in common, interesting ways.
Proposal (FUNCTION-COMPOSITION:JAN89-X3J13):
Add the following functions:
COMPLEMENT function [Function]
Returns a function whose value is the same as the NOT of the
given function applied to the same arguments.
CONSTANTLY value [Function]
Returns a function whose value is always VALUE.
Examples:
(MAPCAR #'(LAMBDA (X) (DECLARE (IGNORE X)) T) '(3 A 4.3))
==
(MAPCAR (CONSTANTLY T) '(3 A 4.3))
=> (T T T)
(FIND-IF-NOT #'ZEROP '(0 0 3))
==
(FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
=> 3
Rationale:
The presence of these functions will contribute to syntactic
conciseness in some cases.
Current Practice:
No Common Lisp implementations provide these functions,
but they do exist in the T language.
Cost to Implementors:
A straightforward implementation is simple to cook up. The definitions
given here would suffice. Typically some additional work might be
desirable to make these open code in interesting ways.
(DEFUN COMPLEMENT (FUNCTION)
#'(LAMBDA (&REST ARGUMENTS)
(NOT (APPLY FUNCTION ARGUMENTS))))
(DEFUN CONSTANTLY (VALUE)
#'(LAMBDA (&REST ARGUMENTS)
(DECLARE (IGNORE ARGUMENTS))
VALUE))
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
(COMPLEMENT BENEFITS)
Benefits:
Some code would be more clear.
Some compilers might be able to produce better code.
Takes a step toward being able to flush the -IF-NOT functions
and the :TEST-NOT keywords, both of which are high on the list
of what people are referring to when they say Common Lisp is
bloated by too much garbage.
Aesthetics:
In situations where these could be used straightforwardly, the
alternatives are far less perspicuous.
Discussion:
Several additional functions (COMPOSE, CONJOIN) were
considered and rejected at the Jan 89 X3J13 meeting.
∂11-Feb-89 0023 CL-Cleanup-mailer Issue: FUNCTION-DEFINITION (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Feb 89 00:23:27 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 FEB 89 00:09:54 PST
Date: 11 Feb 89 00:09 PST
From: masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
Subject: Issue: FUNCTION-DEFINITION (Version 3)
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <890211-000954-4022@Xerox>
!
Issue: FUNCTION-DEFINITION
References: Issue FUNCTION-TYPE
Category: ADDITION
Edit history: 23-Jun-88, Version 1 by Pitman
09-Dec-88, Version 2 by GZ (change name, remove REQUIRED
option, specify first value to be a lambda, add to
discussion and current practice)
10-Feb-89, Version 3, as amended Jan 89 X3J13
Problem Description:
There are portable ways to turn symbols and lists into functions,
but there are no portable ways to get back the original symbols and
lists given the functions.
In many cases, it used to be possible to recover the lambda expression
after a DEFUN by using FUNCTION or SYMBOL-FUNCTION, but the passage of
FUNCTION-TYPE will make this no longer be the case.
Proposal (FUNCTION-DEFINITION:JAN89-X3J13):
Introduce a new function called FUNCTION-LAMBDA-EXPRESSION
which takes as its argument a function and returns three values:
#1: The function's defining lambda expression, or NIL if the information
is not available. The lambda expression may have been pre-processed
in some ways, but it should remain a suitable argument to COMPILE
or FUNCTION.
#2: NIL if the definition was enclosed in the null lexical
environment or something non-NIL if the definition might
have been enclosed in some non-null lexical environment.
#3: the `name' of this function. The name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations are free to always return NIL T NIL, but are encouraged
to return the lambda expression in the case where the argument was created
by an in-core call to COMPILE or EVAL (as opposed to being created by
loading a compiled file).
Examples:
The following examples illustrate some possible return values, but
are not intended to be exhaustive:
#1: (FUNCTION-LAMBDA-EXPRESSION #'(LAMBDA (X) X))
or (FUNCTION-LAMBDA-EXPRESSION
(FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
#2: (FUNCTION-LAMBDA-EXPRESSION
(FUNCALL #'(LAMBDA (X) #'(LAMBDA () X)) NIL))
might return NIL, T, NIL
or (LAMBDA () X), T, NIL
but -not- (LAMBDA () X), NIL, NIL
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION 'BAR) #'FOO)
(FUNCTION-LAMBDA-EXPRESSION #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) (BLOCK FOO X)), T, NIL
or (LAMBDA (X) (BLOCK FOO X)), NIL, FOO
or (SI::BLOCK-LAMBDA FOO (X) X), NIL, FOO
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-LAMBDA-EXPRESSION (FOO))
might return NIL, T, NIL
or (LAMBDA (X) (BLOCK BAR X)), T, NIL
or (LAMBDA (X) (BLOCK BAR X)), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) (BLOCK BAR X)), NIL, "BAR in FOO"
Rationale:
This functionality would be useful to a pretty printer, debugger,
inspector, and other tools.
Cost to Implementors:
The following implementation is technically legitimate, although many
implementations would want to provide something more useful:
(DEFUN FUNCTION-LAMBDA-EXPRESSION (FUNCTION)
(CHECK-TYPE FUNCTION FUNCTION)
(VALUES NIL T NIL))
Current Practice:
Many implementations record this information, but not all that do
publish an interface to extracting the information. VAXLISP and
Lucid call it SOURCE-CODE. Coral calls it UNCOMPILE-FUNCTION.
The language T has this operation and calls it DISCLOSE. It is the
conceptual inverse of the ENCLOSE which occurs in some Scheme dialects,
and is implemented as what CLOS would call a "generic function".
Cost to Users:
None. The change is upward compatible.
Cost of Non-Adoption:
Certain kinds of portable debugging tools would be harder to write.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
The phrase ``program is data; data is program'' comes up a lot in discussions
about Lisp. This makes the case for ``program is data'' more interesting.
Discussion:
The initial name proposed for this function was FUNCTION-DEFINITION. This
was changed because of technical uses of the term ``definition'' to refer
to the entire defining form (e.g. a DEFUN form) rather than the lambda
expression that might be recovered from it.
The possibility of _requiring_ the lambda expression to be available for
all functions created by in-core calls to COMPILE or FUNCTION was considered
but didn't receive much support. Pitman would prefer that option because
it is considerably more useful in practice, but would like to see at least
the current proposal.
Jan 89 X3J13 amended the proposal of Version 2 to change the name
from FUNCTION-SOURCE to FUNCTION-LAMBDA-EXPRESSION.
∂13-Feb-89 1250 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 13 Feb 89 12:46:50 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa10389; 13 Feb 89 20:14 GMT
Date: Mon, 13 Feb 89 20:34:53 GMT
Message-Id: <8378.8902132034@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue PROCLAIM-LEXICAL
To: Jon L White <jonl%lucid.com@NSS.Cs.Ucl.AC.UK>
Cc: jonl <@sail.stanford.edu:jonl@lucid.com>, Moon@scrc-stony-brook.arpa,
sandra <@cs.utah.edu:sandra@defun>, KMP@scrc-stony-brook.arpa,
masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
> Rather than reply to each of the various question you raise, maybe this
> last one is the important one.
Actually, I'm now more confused rather than less. My best guess is
that your objection to special declarations that override a lexical
or global proclamation is that special variables have indefinite
scope. (But lexical variables don't -- they have lexical scope --
so lexical declarations that override are OK.)
But I'm not sure why this is so significant. A special declaration
has a lexically bounded effect: it affects only certain bindings
(actually, at most one) and references. Suppose I never use a special
proclamation. It seems that you would still like to forbid me from
ever using a special variable that had the same name as a global
variable (in the LG sense). And I don't see why. Perhaps I could
see why, but I need an "intuition pump" (Dennett) or something.
Under the LG proposal, as in CL now, I can go around (statically) and
color all lexical and global variable references green and all special
references red. (The green ones are just the ones that are not affected
by a special declaration or proclamation.) The main difficulty in
doing this, so that local inspection isn't quite enough, is the
pervasive effect on bindings of special proclamations; but that
problem was already there and not introduced by LG.
Then, I can always tell what green references refer to. There's
either a locally evident lexical binding -- in which case the
reference is to it -- or else the reference is to the global. Red
references have to be resolved (D or G?) dynamically; but again that's
not something introduced by LG.
> Yes, a proclamation is more pervasive
> than any bounded set of DECLARE's inserted into code.
OK, but I didn't mean a bounded set; I meant every binding. And I
think PROCLAIM ought to correspond to something that can be done with
DECLARE.
> In particular, the DECLAREs (of your examples) are in the same
> lexical scope; but the PROCLAIM might even be in another
> separately-compiled file.
I guess the problem is that I do not see why that is a decisive
factor. Perhaps I picked the wrong example to elaborate.
-- Jeff
∂14-Feb-89 1213 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Feb 89 12:13:45 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 538965; Tue 14-Feb-89 15:11:46 EST
Date: Tue, 14 Feb 89 15:11 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890214151129.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
If someone wants to argue that it's too late to consider things like
this, I won't make serious objection. But I recently battled this
problem yet again and I'm just fed up -- writing up the issue was the
most obvious way I could think of to relieve a little tension. Maybe
enough people will empathize with my feelings on this to help me sneak
it in at the last minute...
-----
Issue: GENSYM-NAME-STICKINESS
Forum: Cleanup
References: GENSYM (p169)
Category: CHANGE
Edit history: 14-Feb-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Many people avoid use of the argument to GENSYM because the argument
is `sticky' and such stickiness can lead to confusion. The problem is
that if any application (usually a macro) uses the gensym argument at
all, then all applications are forced to. If they do not, they risk
finding that the `helpful' argument supplied in some previous call will
be harmful to them.
Proposal (GENSYM-NAME-STICKINESS:WASH-HANDS):
Define that if an optional argument is given to GENSYM, it does NOT
have a side-effect on GENSYM's internal state.
Rationale:
Conscientious programmers are forced now to write their own GENSYM
lookalikes because they know the system's GENSYM has an invasive
effect. This defeats the primary intended function of GENSYM, which
is to satisfy the most common idiomatic use of MAKE-SYMBOL.
The stickiness of the GENSYM prefix was an attempt to be gratuitously
compatible with Maclisp, at the expense of good programming pratice.
Users who need the old behavior of GENSYM can trivially implement
that behavior using MAKE-SYMBOL.
Test Case:
(CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
#\G)
=> NIL ;under CLtL
=> T ;under this proposal
Current Practice:
Symbolics Cloe and Genera are compatible with CLtL, so this would be an
incompatible change.
Cost to Implementors:
Very small.
Cost to Users:
Most uses of GENSYM do not depend on the stickiness of the name, so the
change would be compatible. In some cases, the change would be an
improvement. Even in the worst case where someone depends on stickiness,
it's extremely straightforward to write the couple of lines of code to
produce an application based on MAKE-SYMBOL that is at least as flexible
as GENSYM, and often moreso.
Cost of Non-Adoption:
Good programmers would avoid using the argument to GENSYM (or using
GENSYM altogether) in many situations where they ought not have to.
Benefits:
Gensyms which appear to convey information through their name would not
accidentally pop out and cause confusion in places where they oughtn't.
Aesthetics:
Unnecessary global state changes are hard to reason about. This would
be a small simplification.
Discussion:
Pitman claims to have written a non-sticky GENSYM function for nearly
every one of the dozen or so large systems that he's written or worked
on in the last decade in order to get around the stated problem.
Others have suggested similar experience.
Pitman supports the proposal.
∂14-Feb-89 1328 CL-Cleanup-mailer Re: Issue: GENSYM-NAME-STICKINESS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Feb 89 13:28:11 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 539059; Tue 14-Feb-89 16:26:11 EST
Return-path: <peck@SUN.COM>
Received: from SUN.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 539019; 14 Feb 89 15:55:00 EST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA03383; Tue, 14 Feb 89 12:57:31 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA12283; Tue, 14 Feb 89 12:54:05 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA03628; Tue, 14 Feb 89 12:57:00 PST
Message-Id: <8902142057.AA03628@denali.sun.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: GENSYM-NAME-STICKINESS (Version 1)
In-Reply-To: Your message of Tue, 14 Feb 89 15:11:00 -0500;
<890214151129.1.KMP@BOBOLINK.SCRC.Symbolics.COM> .
Date: Tue, 14 Feb 89 12:56:58 PST
From: peck@Sun.COM
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Tue, 14 Feb 89 16:25 EST
Resent-Message-ID: <890214162556.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
YAY!!! This is what "cleanup" is for.
Go For It!
∂14-Feb-89 1615 CL-Cleanup-mailer Re: Issue: CLOS-CONDITIONS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 89 16:15:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 FEB 89 16:09:30 PST
Date: 14 Feb 89 16:07 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CLOS-CONDITIONS (Version 3)
To: cl-cleanup@sail.stanford.edu
Message-ID: <890214-160930-10914@Xerox>
We need a new version of this proposal that includes option B instead of
option A, and that summarizes some of the arguments recieved. It would be
nice if it could address the issue of error-system-bootstrapping etc that
has concerned some of the community.
First rights go to KMP, as the last author.
Kent?
∂14-Feb-89 1615 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 89 16:15:08 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 FEB 89 15:57:52 PST
Date: 14 Feb 89 15:56 PST
From: masinter.pa@Xerox.COM
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
To: cl-cleanup@sail.stanford.edu
Message-ID: <890214-155752-10883@Xerox>
I'm sorry it has taken me so long to get back to this.
Unfortunately, not all of the mail was cc'd to cl-cleanup, which resulted
in a number of crossed signals.
I have a fairly lengthy conversation initiated by the enclosed message
which transpired between Jan 27 and Jan 30, plus Guy Steele's attempt to
fix the same problem, and the discussion of that, and then a fairly
strongly-worded rejoinder from JonL on the issue.
The status is that Version 5 (i.e., Version 4, with an amendedment) passed
at the January 1989 X3J13 meeting. David has proposed a Version 6, which
I enclose. I'm uncertain whether this version is really unacceptable; it
looks OK to me, and, I think, if I re-read all the mail from Dussud, maybe
it is OK with him too. (Still.)
At the risk of making you repeat yourself, if you have specific
recommendations you think would make Version 6 better than it is now, could
you please restate them?
It will help if we can keep the tone of the discussion low-key. Please keep
perjoratives and characterizations to a minimum.
Thanks,
Larry
----- Begin Forwarded Messages -----
Return-Path: <Moon@ALDERAAN.SCRC.Symbolics.COM>
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by Xerox.COM ;
25 JAN 89 16:32:05 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM
via CHAOS with CHAOS-MAIL id 262758; Mon 23-Jan-89 16:27:19 EST
Date: Mon, 23 Jan 89 16:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
To: RPG@lucid.com, JonL@lucid.com, Dussud@lucid.com, Masinter.pa,
Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19890123212739.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
There were some wording problems with the amended version of
ADJUST-ARRAY-NOT-ADJUSTABLE that was passed at the X3J13 meeting
last week. It ended up not saying what I think was intended.
Two problems:
(1) The amendment made the following function have undefined behavior
in some perfectly meaningful cases, such as the call shown:
(defun double (a)
(if (adjustable-array-p a)
(adjust-array a (* (length a) 2))
(let ((new (make-array (* (length a) 2))))
(replace new a :end1 (length a))
new)))
(double (make-array 30))
(2) The meaning of the SIMPLE-ARRAY type remains unclear. In particular,
it is not clear whether the following function is valid Common Lisp or
can violate the type declaration:
(defun foo ()
(let ((a (make-array 100)))
(declare (simple-array a))
...))
The unamended proposal addressed issue 1, but neither it nor the
amendment addressed issue 2.
I propose to replace the amended proposal, which X3J13 has already voted
in, with the following. Any comments? Should this be sent out in the
upcoming letter ballot? Should I remove the discussion, since the proposal
has in effect been rewritten twice since that discussion occurred?
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289), simple arrays (p28, 289)
Category: CLARIFICATION/CHANGE
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
16-Jan-89, Version 5, by Gabriel. Amended at the meeting to
shorten.
23-Jan-89, Version 6, by Moon. Shorten without the bug
introduced
by the amendment, add clarification of SIMPLE-ARRAY
type.
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' This is inconsistent with
ADJUSTABLE-ARRAY-P.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY.
The definition of the SIMPLE-ARRAY type and its subtypes needs
clarification of its relationship to adjustability.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):
1. ADJUST-ARRAY signals an error if ADJUSTABLE-ARRAY-P of its
first argument is false. ADJUST-ARRAY does not signal an "array
not adjustable" error if ADJUSTABLE-ARRAY-P of its first argument
is true.
2. ADJUSTABLE-ARRAY-P is true of all arrays created with a non-NIL
:ADJUSTABLE option to MAKE-ARRAY. Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
3. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER, and
:DISPLACED-TO arguments each either unspecified or NIL, the resulting
array is a simple array. (This just repeats what CLtL says on page 289,
it's here to aid in understanding the next point.)
4. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments non-NIL, whether the resulting
array is simple is unspecified.
Rationale:
This effectively makes the status quo explicit. This preserves the
raison d'etre of simple arrays, which is to provide a portable interface
to implementation-dependent specialized arrays that trade decreased
functionality for faster access.
Specifying the points left unspecified (requiring all simple arrays to be
non-adjustable and all adjustable arrays to be non-simple) would require
large changes to some implementations and would be of little benefit to
users, merely making one kind of nonconforming program fail in all
implementations instead of failing only in some implementations. Users
need to know that certain arrays are simple, so they can put in
declarations and get higher performance, but users have no need to be
able to create arrays that are definitely non-simple (for lower
performance) or definitely non-adjustable (to cause errors).
The following are logical consequences of this proposal:
Whether an array can be both simple and adjustable is unspecified.
There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
There is no specified way to create an array that is non-simple.
This legitimizes ADJUSTABLE-ARRAY-P as an appropriate predicate to
determine whether ADJUST-ARRAY will reliably succeed.
Examples:
1. The following program is conforming. It is unspecified which branch
of the IF it follows.
(defun double (a)
(if (adjustable-array-p a)
(adjust-array a (* (length a) 2))
(let ((new (make-array (* (length a) 2))))
(replace new a :end1 (length a))
new)))
(double (make-array 30))
2. The following program is conforming. In no implementation is the
type declaration violated.
(let ((a (make-array 100)))
(declare (simple-array a))
(frob a))
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and ignores adjustability in deciding whether an array is simple,
and is compatible with this proposal.
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
in all cases, and make all arrays non-simple unless the Common Lisp
language requires them to be simple, and are compatible with this
proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to
change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic. Having an aspect of
the language explicitly unspecified is more aesthetic than having it
implicitly unspecified on account of vague or inconsistent documentation.
Discussion:
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
----- End Forwarded Messages -----
∂14-Feb-89 1636 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 89 16:35:58 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 FEB 89 16:22:17 PST
Date: 14 Feb 89 16:21 PST
From: masinter.pa@Xerox.COM
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 7)
To: cl-cleanup@sail.stanford.edu
Line-fold: NO
Message-ID: <890214-162217-10951@Xerox>
I'm sorry for introducing version 6, which was incorrect.
I believe this is closer to the wording we voted on.
KMP points out that this may have been a bad amendment,
which is separate from the issue of whether we've accurately
reflected what was voted on.
If the amendment is wrong, we could vote to reconsider &
revoke the amendment. I'm not swayed strongly enough by
Kent's arguments to bring this issue up again myself,
however.
!
Status: Passed, as amended, Jan 89 X3J13
Forum: Cleanup
Issue: CLOSED-STREAM-OPERATIONS
References: CLOSE (CLtL p 332)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
8-Oct-88, Version 2 by Masinter
13-Oct-88, Version 3 by van Roggen
1-Dec-88, Version 4 by Pitman
5-Dec-88, Version 5 by Masinter (separate other issues)
3-Feb-89, Version 6 by Masinter (as per Jan 89 X3J13)
14-Feb-89, Version 7 by Masinter (correct error in 6)
Related Issues: STREAM-ACCESS, STREAM-INFO, INPUT-STREAM-P-CLOSED,
CLOSE-CONSTRUCTED-STREAMS, PATHNAME-STREAM
Problem Description:
The description of CLOSE is not completely clear about the functions
which are allowed to be performed on a closed stream.
On p332 it says:
``The stream is closed. No further Input/output operations may be
performed on it. However, certain inquiry operations may still
be performed, ...''
but the list of inquiry operations is not specified.
Proposal (CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY)
Clarify the behavior of the following functions on closed streams:
* STREAMP is unaffected by whether its stream argument is open or closed.
* If CLOSE is called on a stream which is open, it will return T.
However, if CLOSE is called on a stream which is closed, it
will succeed with out error but the return value will be NIL.
* PATHNAME is valid on either an open or closed stream. Since some
implementations cannot provide the truename of a file until the
file is closed, it would in principle be possible for PATHNAME in
some implementations to return more specific information after the
stream is closed. For consistency, however, PATHNAME is prohibited
from doing this. PATHNAME must return the same pathname after a
file is closed as it did before. (The passed proposal in issue
PATHNAME-STREAM still stands.)
* TRUENAME is valid on either an open or closed stream. Since some
implementations cannot provide the truename of a file until the
file is closed, it is permissible TRUENAME to return more specific
information after the stream is closed.
* MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY,
PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING,
FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING,
ENOUGH-NAMESTRING, and OPEN are valid on either open or closed streams.
For any of these operations, using a stream, S, as an argument
where appropriate is equivalent to using (PATHNAME s). See the
description of PATHNAME above to understand the consequences of this.
* PROBE-FILE and DIRECTORY are valid on either open or closed streams.
For either of these operations, using a stream, S, as an argument
where appropriate is equivalent to using (PATHNAME s). See the
description of PATHNAME above to understand the consequences of this.
In this case of these operators however, closed stream may well be the
most reliable arguments in some cases, since treatment of open streams
to the file system may vary considerably between implementations.
For example, in some operating systems, open files are written under
temporary names and not renamed until close and/or are held invisible
until a close is performed. In general, any code with an intent to be
highly portable should tread lightly when using PROBE-FILE or
DIRECTORY.
Rationale:
One can consider many characteristics of a stream to be independent of
the ability to do I/O. Being able to determine a stream's direction and
its name is often useful for debugging. A number of the descriptions in
CLtL imply (weakly) the ability to work on closed streams. Functions
such as OPEN and DIRECTORY don't really depend on the stream, but on
the name of the stream.
Current Practice:
At least two implementations differ in which functions are allowed to be
performed on a closed stream.
Cost to Implementors:
Unknown, but likely to be small in most implementations.
A nontrivial amount of work may be necessary if the pathname information
is held externally and is normally deleted when the stream is closed.
The implementation will have to copy the information at some time for later
inquiries.
Cost to Users:
Likely to be small; users of an implementation forced to change
by this proposal might have to make some modifications to make their
programs portable.
Benefits:
These clarifications will assist users in writing portable code.
Aesthetics:
Most people will probably see these clarifications as an improvement
in aesthetics.
Discussion:
There are some separate, but related, issues regarding what CLOSE
should do on composite streams or constructed streams such as
created by MAKE-BROADCAST-STREAM. These issues will be addressed
in a separate issue (CLOSE-CONSTRUCTED-STREAMS).
There was some discussion on whether INPUT-STREAM-P and OUTPUT-STREAM-P
should return "false" on a stream that had been closed. The issue
STREAM-ACCESS contains a proposal to add a function OPEN-STREAM-P
which might be useful for the same purpose. This issue was separated
out into a separate issue (INPUT-STREAM-P-CLOSED).
The other functions in proposal STREAM-ACCESS:PROVIDE should
work on closed streams.
The functions in STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS should
not be requred to work on closed streams.
----- End Forwarded Messages -----
----- End Forwarded Messages -----
∂14-Feb-89 1658 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 89 16:52:29 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 FEB 89 16:36:01 PST
Date: 14 Feb 89 16:34 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: COERCE-INCOMPLETE (Version 2)
To: cl-cleanup@sail.stanford.edu
Message-ID: <890214-163601-10990@Xerox>
The last mail on this topic was 30-Dec-88.
We can either release version 2 (of 21-Nov-88), someone can produce a new
version, or we can drop it.
I'm inclined toward dropping the issue, even though some of the extensions
"would be nice". I think David's message of 30-Dec is in agreement.
Yes, the FUNCTION-TYPE issue already extended COERCE to deal with
'FUNCTION.
∂15-Feb-89 0646 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Feb 89 06:46:33 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 539457; Wed 15-Feb-89 09:43:48 EST
Date: Wed, 15 Feb 89 09:43 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890214-155752-10883@Xerox>
Message-ID: <890215094330.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
The message you sent to CL-Cleanup is only the earliest of a lot of
messages from that private conversation. To avoid replaying that whole
conversation, I offer here a summary of the discussion. For brevity,
I have paraphrased rather than quoted.
RPG - This proposal (v6) says ADJUST-ARRAY must signal. CLtL says
``is an error.''
Moon - This introduction of incompatible change was not intentional.
Still, ``must signal'' doesn't seem bad.
RPG - Eliminates option of ignoring error checking in highly optimized code.
Pitman - Can we compromise on ``should signal'' ?
RPG - OK.
RPG - Not sure if this is implied, should add:
5. The value of ADJUSTABLE-ARRAY-P on a simple array is unspecified.
No one objected.
RPG - Alternate presentation, incorporating new items and clarifications
per above, and changing subtle aspects of the presentation:
1. ADJUSTABLE-ARRAY-P is true of all arrays created with a true
:ADJUSTABLE option to MAKE-ARRAY. Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
2. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
3. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
4. If ADJUST-ARRAY is invoked on an array that was created without
supplying :ADJUSTABLE true, an error should be signaled, unless
ADJUSTABLE-ARRAY-P returns true on that array. ADJUST-ARRAY must
not signal the error if ADJUSTABLE-ARRAY-P is true for its first
argument.
5. The value of ADJUSTABLE-ARRAY-P on a simple array is unspecified.
KMP - Looks ok.
No one else commented.
∂15-Feb-89 0706 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Feb 89 07:06:08 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 539477; Wed 15-Feb-89 10:03:58 EST
Date: Wed, 15 Feb 89 10:03 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 7)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890214-162217-10951@Xerox>
Message-ID: <890215100339.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
What's weird about this whole thing is that CLOSE-CONSTRUCTED-STREAM
talks about the effect of most operations being `unspecified' after
close.
Unless you intend it to be an implication of CLOSE-CONSTRUCTED-STREAM
that you actually carry a CLOSED-P bit around in every stream so you
can tell if the stream is open or not and return the right value from
CLOSE, then it's a bad idea to legislate that CLOSE returns a certain
value, because you can't really guarantee that value.
If you do intend me to carry around a CLOSED-P bit, why bother to
claim that the effect of I/O to the stream after it's closed is
`unspecified.' My assumption before was that it was unspecified in
case I want to define it, but suddenly it sounds like I'm not really
allowed to extend it -- I'm just permitted to optimize out the error
checks for the sake of efficiency. If this is so, why not just put it
in the domain of `should signal' so that at least the users could get
some mileage out of it because my implementation pretty much has its
hands tied at this point.
We get calls all the time from users who claim we're in violation of
things that really CLtL leaves vague. This will be such a thing given
the way it's all worded.
Here I am implementing CLOSE. I -really- want to implement it correctly.
I am willing to do anything necessary to make it return the right value
as long as what I do is something that is backed up in writing.
Here you are designing CL -- creating the writing that will back me up.
If you cannot show me how to write CLOSE in a way so that I can simply
point to a sentence in the manual that explains off my behavior whenever
anyone complains so I can get them off the phone and get back to work,
then you owe me a sentence in the manual that says that I'm entitled to
do whatever I feel like and the user cannot depend on it.
False security is worse than no security at all.
∂15-Feb-89 0737 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Feb 89 07:37:38 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 539495; Wed 15-Feb-89 10:35:22 EST
Date: Wed, 15 Feb 89 10:35 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: COERCE-INCOMPLETE (Version 2)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890214-163601-10990@Xerox>
Message-ID: <890215103505.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 14 Feb 89 16:34 PST
From: masinter.pa@Xerox.COM
The last mail on this topic was 30-Dec-88.
We can either release version 2 (of 21-Nov-88), someone can produce a
new version, or we can drop it.
I don't think it's our job to make the decision, only to make the
options clear. I think the real options are:
1. STATUS-QUO: Leave COERCE alone (modulo extensions per FUNCTION-TYPE).
2. EXTEND: Extend COERCE per version 2 (since it's already written up).
3. DEPRECATE: Deprecate COERCE.
I don't think we have the authority to simply pocket veto the issue,
especially given that the user community (in this case `Japan') has
indicated that this is important to them. It deserves to at least come
to a full vote in some form.
I'm inclined toward dropping the issue, even though some of the extensions
"would be nice". I think David's message of 30-Dec is in agreement.
I suggest we take version 2, add an option to deprecate and an option
for status quo, and then declare our work done on it and just leave it
up to the committee to resolve this by 3-way vote. I'm willing to do the
writing.
Yes, the FUNCTION-TYPE issue already extended COERCE to deal with
'FUNCTION.
∂15-Feb-89 0817 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Feb 89 08:16:55 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01940g; Wed, 15 Feb 89 08:09:39 PST
Received: by challenger id AA03972g; Wed, 15 Feb 89 08:03:49 PST
Date: Wed, 15 Feb 89 08:03:49 PST
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8902151603.AA03972@challenger>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 14 Feb 89 15:56 PST <890214-155752-10883@Xerox>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Date: 14 Feb 89 15:56 PST
From: masinter.pa@Xerox.COM
The status is that Version 5 (i.e., Version 4, with an amendedment) passed
at the January 1989 X3J13 meeting. David has proposed a Version 6, which
I enclose. I'm uncertain whether this version is really unacceptable; it
looks OK to me, and, I think, if I re-read all the mail from Dussud, maybe
it is OK with him too. (Still.)
This version is OK with me.
∂15-Feb-89 0835 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Feb 89 08:35:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 FEB 89 08:28:18 PST
Date: 15 Feb 89 08:27 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 15 Feb 89 09:43 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890215-082818-12355@Xerox>
Yes, there was lots of subsequent discussion. However, it remains that I
only have version 6. One of the following can happen:
Someone can write Version 7
We can release Version 6
We can let Version 5 (i.e., as amended at the meeting) stand.
We can vote to rescind version 5 at the next meeting.
I can't think of any other options. Which do you prefer?
∂15-Feb-89 1000 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Feb 89 09:57:12 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08188; 15 Feb 89 17:19 GMT
Date: Wed, 15 Feb 89 17:41:50 GMT
Message-Id: <4398.8902151741@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
To: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@com.xerox's message of 14 Feb 89 15:56 PST
> The description of ADJUST-ARRAY on pp297-298 says that it is
> ``not permitted to call ADJUST-ARRAY on an array that was not
> created with the :ADJUSTABLE option.'' This is inconsistent with
> ADJUSTABLE-ARRAY-P.
Well, the other sections don't say anything explicitly, and this one
does; so why doesn't this one take precedence?
> Specifying the points left unspecified (requiring all simple arrays to be
> non-adjustable and all adjustable arrays to be non-simple) would require
> large changes to some implementations and would be of little benefit to
> users, merely making one kind of nonconforming program fail in all
> implementations instead of failing only in some implementations.
This is kind of strange. I think it's a good thing when nonconforming
programs fail everywhere, and not something we should just dismiss.
We should allow such differences only when there are good reasons to
do so.
> Users
> need to know that certain arrays are simple, so they can put in
> declarations and get higher performance, but users have no need to be
> able to create arrays that are definitely non-simple (for lower
> performance) or definitely non-adjustable (to cause errors).
Surely the performance of an array with certain characteristics
is the same whether or not we say it's simple. So creating arrays
that are definitely non-simple is not a request for lower performance.
> Pitman wishes some of the other proposals were economically feasible to
> pursue but reluctantly agrees that maintaining (and clearly documenting)
> the status quo is probably the most reasonable avenue left to us.
Sigh.
∂15-Feb-89 1124 CL-Cleanup-mailer [Moon@STONY-BROOK.SCRC.Symbolics.COM: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)]
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Feb 89 11:24:16 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 539743; Wed 15-Feb-89 14:22:16 EST
Date: Wed, 15 Feb 89 14:21 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [Moon@STONY-BROOK.SCRC.Symbolics.COM: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)]
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890215-082818-12355@Xerox>
References: <19890123212739.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890215142157.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 15 Feb 89 08:27 PST
From: masinter.pa@Xerox.COM
... it remains that I only have version 6. ... Someone can
write Version 7 ...
Ok, you asked for it... This version makes the following changes:
- It makes adjust array `should signal' rather than `must signal'
in the array-not-adjustable case. I believe this to be the only
`consequential' difference between this and version 6.
- It uses RPG's presentation for the proposal, except for RPG's
item #4 (Moon's item #1). I've used Moon's presentation style
but have effectively added RPG's presentation under
"Clarifications and Logical Consequences". Hopefully that will
make things doubly clear.
- I've moved "the clarifications up above the rationale" so that
they feel more like an extension of the proposal itself.
- I've split paragraph 2 of the Rationale into two paragraphs,
adding a sentence at the end of the new paragraph 2 to help
address Jeff's perception that we were characterizing error
detection as an activity without value.
- Everything else is pretty much left untouched.
-----
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289), simple arrays (p28, 289)
Category: CLARIFICATION/CHANGE
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
16-Jan-89, Version 5, by Gabriel. Amended at the meeting to shorten.
23-Jan-89, Version 6, by Moon. Shorten without the bug introduced
by the amendment, add clarification of SIMPLE-ARRAY type.
15-Feb-89, Version 7, by Pitman. Minor changes per comments from
RPG and Dalton.
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' This is inconsistent with
ADJUSTABLE-ARRAY-P.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY.
The definition of the SIMPLE-ARRAY type and its subtypes needs
clarification of its relationship to adjustability.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):
1. ADJUSTABLE-ARRAY-P is true of all arrays created with a true
:ADJUSTABLE option to MAKE-ARRAY. Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
2. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
3. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
4. ADJUST-ARRAY ``should signal'' an error if ADJUSTABLE-ARRAY-P
of its first argument is false. ADJUST-ARRAY must not signal an
`array not adjustable' error if ADJUSTABLE-ARRAY-P of its first
argument is true.
5. The value of ADJUSTABLE-ARRAY-P on a simple array is unspecified.
Note: ``should signal'' is taken from the new error terminology.
It means that in ``safe code'' (code compiled with highest safety)
an error must be signalled, but that in unsafe code (code not compiled
with highest safety), an error might or might not be signalled.
Clarifications and Logical Consequences:
a. Whether an array can be both simple and adjustable is unspecified.
b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
c. There is no specified way to create an array that is non-simple.
d. This legitimizes ADJUSTABLE-ARRAY-P as an appropriate predicate to
determine whether ADJUST-ARRAY will reliably succeed.
e. If ADJUST-ARRAY is invoked on an array that was created without
supplying :ADJUSTABLE true, an `array not adjustable' error
``should be signalled'' unless ADJUSTABLE-ARRAY-P returns true on
that array (in which case it must not signal an `array not adjustable'
error).
Rationale:
This effectively makes the status quo explicit. This preserves the
raison d'etre of simple arrays, which is to provide a portable interface
to implementation-dependent specialized arrays that trade decreased
functionality for faster access.
Specifying the points left unspecified (requiring all simple arrays to be
non-adjustable and all adjustable arrays to be non-simple) would require
large changes to some implementations and would be of little benefit to
users, merely making one kind of nonconforming program fail in all
implementations instead of failing only in some implementations. The
argument here is not that the error checking would not be useful for
developers of portable code, but only that the cost of introducing that
error checking would be exceedingly high for some implementations.
Users need to know that certain arrays are simple, so they can put in
declarations and get higher performance, but users have no need to be
able to create arrays that are definitely non-simple (for lower
performance) or definitely non-adjustable (to cause errors).
Examples:
1. The following program is conforming. It is unspecified which branch
of the IF it follows.
(defun double (a)
(if (adjustable-array-p a)
(adjust-array a (* (length a) 2))
(let ((new (make-array (* (length a) 2))))
(replace new a :end1 (length a))
new)))
(double (make-array 30))
2. The following program is conforming. In no implementation is the
type declaration violated.
(let ((a (make-array 100)))
(declare (simple-array a))
(frob a))
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and ignores adjustability in deciding whether an array is simple,
and is compatible with this proposal.
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
in all cases, and make all arrays non-simple unless the Common Lisp
language requires them to be simple, and are compatible with this proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic. Having an aspect of
the language explicitly unspecified is more aesthetic than having it
implicitly unspecified on account of vague or inconsistent documentation.
Discussion:
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
∂15-Feb-89 1126 CL-Cleanup-mailer Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Feb 89 11:26:18 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 FEB 89 11:16:23 PST
Date: 15 Feb 89 11:12 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 15 Feb 89 13:54 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK,
cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890215-111623-12827@Xerox>
> [CL-Cleanup removed to avoid repeating a debate that I'd thought was
> settled. Masinter retained just so he knows this exchange occurred.]
Those who send private mail have to take the risk of having to see their
arguments repeated.
I think that the only issue we really have the charter to attack is to
"fix" what we think was a mistake in the wording of the amendment that
was accepted at the last meeting.
I don't think we should revisit the issue itself. The intent at the X3J13
meeting was to endorse a proposal where ADJUST-ARRAY might in fact
work in some implementations on arrays that were made with :ADJUSTABLE
NIL as long as they were ADJUSTABLE-ARRAY-P. We think that the
amendment made to achieve that purpose also made some other programs
which we think are portable now invalid/non-conformal, and so lets fix that.
I see no reason to reconsider the entire issue.
The question remains: does Version 6 adequately fix the "mistake" made
in Version 5? Dussud and Moon think so.
Do KMP and RPG disagree? I'm unclear about whether the "Alternate presentation"
from RPG is meant as an improvement over Version 6.
∂15-Feb-89 1206 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Feb 89 12:05:55 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 539797; Wed 15-Feb-89 15:03:40 EST
Date: Wed, 15 Feb 89 15:03 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890118142113.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890215150320.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Here's some questions/comments that need to be factored into the
next draft on this issue...
1. Moon has suggested that COPY-CONDITION is not necessary. Does anyone
disagree? I am willing to remove it, but doing so will make this
proposal less `compatible.' I don't care much one way or the other, but
I don't want to be accused of being `callous' toward people who do care.
If this committee will back me up on the removal of that function and
the resulting compatibility problems that could in principle (though
perhaps not in practice) come up, then I'll make the change. Opinions?
2. Moon has also asked that the syntax to SIGNAL-WITH-RESTARTS and
ERROR-WITH-RESTARTS be:
SIGNAL-WITH-RESTARTS signal-argument-list &rest restart-clauses
ERROR-WITH-RESTARTS signal-argument-list &rest restart-clauses
so that you would write
(SIGNAL-WITH-RESTARTS ('FOOD-COLOR-ERROR :FOOD 'LETTUCE :COLOR 'PINK)
...restart clauses...)
rather than
(SIGNAL-WITH-RESTARTS (MAKE-CONDITION 'FOOD-COLOR-ERROR
:FOOD 'LETTUCE :COLOR 'PINK)
...restart clauses...)
If you wanted to use MAKE-CONDITION, you would then write:
(SIGNAL-WITH-RESTARTS ((MAKE-CONDITION 'FOOD-COLOR-ERROR
:FOOD 'LETTUCE :COLOR 'PINK))
...restart clauses...)
The advantage of what he proposes is that you could write
(SIGNAL-WITH-RESTARTS ("Bad ~S color" 'FOOD)
...restart clauses...)
and a condition object would be created implicitly as with SIGNAL. A
possible disadvantage is that
(SIGNAL-WITH-RESTARTS (FOO BAR BAZ)
...restart clauses...)
might look to someone like the FOO in (FOO BAR BAZ) named a function
rather than a variable. Does anyone else have an opinion on this?
3. Rees has suggested that the syntax for WITH-CONDITION-RESTARTS should be
WITH-CONDITION-RESTARTS condition-form restarts-form &BODY forms
rather than
WITH-CONDITION-RESTARTS (condition-form restarts-form) &BODY forms
which it is now. Does anyone else have an opinion?
4. Rees has asked for advice about how the condition/restart association
might be implemented -- is some kind of alist structure held by a
special variable what was intended, or ought the condition have a
restarts slot. He and I talked a little about this and eventually he
agreed that it's pretty obvious that the relation should be externally
represented. It's important that the association not be done by a slot
in the condition because if you carry around the condition object after
you're done signalling, you don't want it to contain useless and/or
misleading information about restarts that no longer exist. I'll probably
add some notes to this effect when I generate the next draft.
This doesn't really require comment, unless someone seriously disagrees.
∂15-Feb-89 1244 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Feb 89 12:42:51 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09338; 15 Feb 89 20:12 GMT
Date: Wed, 15 Feb 89 20:34:12 GMT
Message-Id: <4922.8902152034@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Issue: READ-CASE-SENSITIVITY (Version 1)
To: CL-Cleanup@sail.stanford.edu
Cc: richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
It may be rather late for new issues, but I think this one should
still be considered. The proposal below is fairly minimal. More
far-reaching proposals, or ones that are better in other ways, are
also possible; but this seems a good place to start.
A longstanding problem in Common Lisp is that the reader always
converts unescaped characters in symbol names to upper case.
This makes a number of applications more difficult than they
should be and looks like an oversight (especially given the
existence of *PRINT-CASE*).
This problem is an easy target for critics of Common Lisp and
tends to imflame opinion. Here are three comments I have seen
recently in the UK:
[...] particular small lunacies (e.g. the printer can be parameterised
to case fold everything to lower case, but the reader ALWAYS folds
to upper case, which is a real nasty for people who would like
to write their own code in case sensitive styles with Car, CAR and car
baing different. E.g. it means that using the Lisp reader to accept
(as a cheap way of so doing) natural language stuff from the user
necessarily loses capitalisation, which is STUPID. I also happen to
consider it ill-judged and a throw-back the TTY33s and punched cards
to work in UPPER CASE FOR ALL LISP INTERNAL DATASTRUCTURES, SINCE I
RATHER EXPECT MOST CURRENT PROGRAMMING STYLE IS BASED AROUND USE OF
LOWER OR MIXED CASE.
I also have a feeling the it is perpetuating the punched card era to
have a so called modern language work entirely in upper case inside
itself, and amazing to go to the trouble for case folding on both
input and output to paper over this, and even more bizzare to make the
output folding optional but not the input...)
The single thing which is left which most upsets me is the bloody
upper-case only reader - I *can't believe* that anyone thinks that's
a good idea.
Of course, it is not just to answer such criticism that I propose
this change.
-----
Issue: READ-CASE-SENSITIVITY
Forum: Cleanup
References: CLtL p 334 ff: What the Read Function Accepts;
especially p 337.
*PRINT-CASE* (CLtL, p 372)
Category: ADDITION/CHANGE
Edit history: 15-Feb-89, Version 1 by Dalton
Status: For Internal Discussion
Problem Description:
The Common Lisp reader always converts unescaped constituent
characters to upper case. (See CLtL, p 337, step 8, point 1.)
Proposal (READ-CASE-SENSITIVITY:LIKE-PRINT-CASE)
Add a new read parameter, *READ-CASE*, to control case
sensitivity. By analogy with *PRINT-CASE*, it may take the
following values:
:UPCASE -- convert unescaped characters to upper-case, as now.
:DOWNCASE -- don't convert, leaving lower-case letters in lower
case.
This proposal does not provide a way to tell the reader to convert
upper-case letters to lower-case. This is consistent with *PRINT-
CASE*, which does not provide a way to print lower-case letters in
upper-case.
Note that an isomorphic proposal that would not emphasise an
analogy with *PRINT-CASE* would be to add a parameter called
*READ-CASE-SENSITIVE*, taking the values T (to preserve case)
or NIL (to convert to upper case). Yet another proposal might
be to add a function READ-PRESERVING-CASE (hee hee).
Rationale:
There are several reasons for this proposal.
1. Lisp applications often use the Lisp reader to read their data.
This is often significantly easier than writing input routines
from scratch, especially if the input can be structured as lists.
However, certain applications want to make use of case distinctions,
and Common Lisp makes this unreasonably difficult. (You must define
every letter as a read macro and have the macro function read the
rest of the symbol.)
2. Some programming languages distinguish between upper and lower
case in identifiers, and useful conventions are often built around
such distinctions. For example, in C, constants are often written
in upper case and variables in lower. In Mesa(?) and Smalltalk(?),
a capital letter is used to indicate the beginning of a new word
in identifiers made up of several words. In Edinburgh Prolog,
variables begin with upper-case letters and constant symbols do
not. The case-insensitivity of the Common Lisp reader makes
it difficult to use conventions of this sort.
3. Among Lisp dialects, Common Lisp gives an unusual degree of
control over the case of output. However, there is no control over
the treatment of case on input. This makes the language unbalanced.
We live in a mixed-case world, and it should be possible to make use
of case distinctions in Common Lisp.
Test Case:
(let ((*read-case* :downcase))
(read-from-string "Zebra"))
= ZEBRA ;under CLtL
= |Zebra| ;under this proposal
Current Practice:
I do not know of any implementation that implements this proposal.
Franz Inc's ExCL has (or at least had) a function, excl:set-case-mode,
that set both the "preferred case" (the case of character in the print
names of standard symbols such as CAR) and whether or not the reader
was case-sensitive.
Cost to Implementors:
Fairly small.
Cost to Users:
None, this is a compatible change from the user's standpoint.
Cost of Non-Adoption:
Applications that want to read mixed-case expressions will not
be able to use the Common Lisp reader to do so (except, perhaps,
by tortuous use of read macros).
Programming styles that rely on case distinctions (without escape
characters) will be impossible.
Benefits:
Applications will be able to read mixed-case expressions.
Programmers will be able to make use of case distinctions.
Aesthetics:
For the proposal:
The language will have greater symmetry.
The language will look less old-fashioned.
Against the proposal:
The addition of another global parameter to control yet another
aspect of I/O is inelegant and increases clutter.
In favor of additional or more far-reaching changes:
Anyone wishing to make use of case distinctons in Lisp programs
will have to write the names of symbols in the "LISP" package in
upper case.
Discussion:
Larry Masinter suggested at one point that case sensitivity could
be an aspect of read tables rather than a separate parameter.
There may be several ways of doing this. For example, it might
be a property of each character or of the table as a whole.
An interesting possibility would be to disguise the preferred
internal case by defining a value for *READ-CASE* called :INVERT.
If the value were :INVERT, mixed-case symbols would remain the same
(or perhaps they would be inverted too) but all upper case input
would specify a lower-case name internally, and vice versa.
You may recall that something similar was suggested for pathnames.
Dalton supports the proposal LIKE-PRINT-CASE.
∂15-Feb-89 1331 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Feb 89 13:31:01 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 539857; Wed 15-Feb-89 16:28:54 EST
Date: Wed, 15 Feb 89 16:28 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: READ-CASE-SENSITIVITY (Version 1)
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: CL-Cleanup@sail.stanford.edu,
richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
In-Reply-To: <4922.8902152034@subnode.aiai.ed.ac.uk>
Message-ID: <890215162833.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
I appreciate your good intentions in writing this proposal, however I
do not agree that the proposal satisfies its stated goals without
intruding.
I will begin by making a few remarks about case-sensitivity, how (by
my recollection) we came to the state that we're in, and why I don't
think the state is as bad as portrayed. Then I'll move to criticisms
of the proposal itself, and finally to suggestions about alternate
ways to proceed if you want to pursue this further.
EQ symbols cannot print differently in different places without help
from some global context switch. *PRINT-CASE* is such a switch.
If case is -ever- to be signficant, case must be preserved internally.
That is, to even accomodate the idea that |CAR| and |car| might denote
different symbols, it is necessary to define that the internal
representation distinguishes |CAR| from |car|. CLtL indicates that this
is true.
If case is significant internally, then every symbol must have a
well-defined internal casing in order to be found. That is, since by the
previous paragraph |CAR| is distinct from |car|, we must say whether CAR
denotes the former or the latter.
An arbitrary choice must be made between whether CAR maps to |CAR| or
|car|. Otherwise, when you do (DEFUN CAR ...), you have to create
symbols |CAR|, |CAr|, |CaR|, |Car|, |cAR|, |cAr|, |caR|, and |car| and
put the definition in all of them in order to not cause confusion when
you later do (Car x).
Some case had to be chosen. The arbitrary choice made was uppercase.
Personally I think this was the right choice, but I recognize that others
would have preferred lower. In any case, the operative word is "arbitrary".
Any change at this point would be de-stabilizing to no good end.
If lowercase had been chosen, we might be listening to uppercase enthusiasts
complain that lowercase looks dumb. In the end, that form of argument has
to be discounted as useless because it cannot lead to a resolution that will
be happy for all.
What should be the issue is: what options and tools can we provide that
allow as wide a variety of user programming styles as possible without
breaking the ability to load code written by different programmers into
the same environment.
*PRINT-CASE* was very carefully chosen after a -huge- amount of
discussion to permit flexibility -without- affecting the semantic
correctness of code. That is, if you set *PRINT-CASE* globally, you
don't interfere with the correct operation of libraries that others
have written, regardless of whether their original program or
runtime data is uppercase, lowercase, or mixed case.
On the other hand, your proposed *READ-CASE* does not have this property.
You could not set it reliably because you would never know when some
macro or some data-manipulating utility would call something like
READ-FROM-STRING behind your back and get screwed because you'd changed
the semantics of that operation. It would therefore not contribute to
modularity.
In spite of what I would characterize as superficial criticisms from
people about Common Lisp and/or *PRINT-CASE*, I think that in fact we
have made a very reasonable compromise between flexible style and the
need for programs to snap together reliably. Your *READ-CASE* proposal
is incomplete because the test case does not show the calling of a
built-in function. Leaving aside issues of what would out and out break
if you set *READ-CASE* to :DOWNCASE, you'd end up having to write
(CAR Zebra)
rather than being able to write (as you already can)
(Car Zebra)
for example. I personally think this is ugly, and I think many novices
would mis-read the documentation and believe that if they set this
variable, they could use lowercase ... only to find that they got
confusing undefined-function warnings which they do not currently get.
A more technically reasonable alternate solution might be to extend
*PRINT-CASE* to take a sort of alist as a value. Eg, consider:
((ZEBRA . "Zebra") :UPCASE)
so that you could override the casification of some words on a
case-by-case basis and then fall through to a general rule. However,
my guess is that while this is technically workable, it would be
too tedious in practice (and perhaps to computationally expensive
for the printer if the alist got very long).
I am also ammenable to the idea of creating a portable way to modify
the readtable to turn off case translation. We should strongly discourage
people from doing this to the default readtable because it would have an
invasive effect on programs they didn't control and perhaps didn't even
realize existed, but the idea of constructing private readtables that
don't case-translate for whatever purposes seems highly reasonable.
This would address points #1 and #2 in your rationale, which I agree is
an excellent point. [Btw, that sort of thing should be in the problem
description.]
Point #3 of the Rationale is, as I've discussed, not a problem but a
feature. It's perhaps not as strongly motivated in the writeup as it
might be, but I stand by it strongly.
Regarding your final `Rationale' statement: ``We live in a mixed-case
world, and it should be possible to make use of case distinctions in
Common Lisp.'' I agree only to the extent that it does not harm
program modularity. My two counter-suggestions above are intended to
help clarify the point that I am not objecting to your problem
description as unreasonable but rather to your solution as overly naive.
Also, following directly from my above remarks, your Cost of Users is
drastically understated. The feature is not compatible since the very
presence of *READ-CASE* would mean that programs would not snap together
reliably if this variable were ever set. In practice, this would mean
that any call to READ would have to be surrounded by a binding of
*READ-CASE* just in case. Rather than your whimsy suggesting of
READ-PRESERVING-CASE, you'd end up with a desperate need for
READ-IGNORING-CASE all over the place just in case you ever loaded into
a hostile environment where READ did not behave as expected.
Regarding your statement of Aesthetics, I certainly don't think the
addition of another switch would be a big deal if it would buy something
useful in a non-invasive way.
One parting remark, I think the proposal name LIKE-PRINT-CASE is confusing.
I would have expected that to mean `things typed in get downcased.' Only
pragmatics would tell me this is ludicrous. Since I sometimes suspect
that some people don't really read much if any of these writeups and that
these proposal names end up having undue weight, I'd prefer something else.
Ok, two parting remarks, :DOWNCASE should really be :DONT-UPCASE since it
doesn't really distinguish :CAPITALIZE from :DOWNCASE.
Anyway, as it stands, Pitman is steadfastly opposed to LIKE-PRINT-CASE
for the stated reasons.
∂15-Feb-89 1435 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Feb 89 14:35:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 FEB 89 13:53:33 PST
Date: 15 Feb 89 13:53 PST
From: cutting.pa@Xerox.COM
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 15 Feb 89 16:28 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: jeff@aiai.edinburgh.ac.uk, CL-Cleanup@sail.stanford.edu,
richard@aiai.edinburgh.ac.uk
Message-ID: <890215-135333-1329@Xerox>
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 15 FEB 89
13:31:21 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
SAIL.Stanford.EDU with TCP; 15 Feb 89 13:31:01 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 539857; Wed
15-Feb-89 16:28:54 EST
Date: Wed, 15 Feb 89 16:28 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
*PRINT-CASE* was very carefully chosen after a -huge- amount of
discussion to permit flexibility -without- affecting the semantic
correctness of code. That is, if you set *PRINT-CASE* globally, you
don't interfere with the correct operation of libraries that others
have written, regardless of whether their original program or
runtime data is uppercase, lowercase, or mixed case.
On the other hand, your proposed *READ-CASE* does not have this property.
You could not set it reliably because you would never know when some
macro or some data-manipulating utility would call something like
READ-FROM-STRING behind your back and get screwed because you'd changed
the semantics of that operation. It would therefore not contribute to
modularity.
How is *READ-CASE* any different than *PACKAGE*, *READ-BASE* and
*READTABLE* in this respect? They all change the semantics of
READ-FROM-STRING, occasionally even screwing things up. There is
precedent.
∂15-Feb-89 1509 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Feb 89 15:09:31 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 539957; Wed 15-Feb-89 18:07:11 EST
Date: Wed, 15 Feb 89 18:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: cutting.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, jeff@aiai.edinburgh.ac.uk,
CL-Cleanup@sail.stanford.edu, richard@aiai.edinburgh.ac.uk
In-Reply-To: <890215-135333-1329@Xerox>
Message-ID: <890215180644.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
That's quite a reasonable point -- for *READ-BASE* especially --
however, I am not devoid of remarks to make...
1. It is arguably necessary to vary *PACKAGE* in order to
achieve a certain kind of modularity. Indeed, a certain amount
of confusion is almost intentional in the package system in
this regard. There is `deliberate ambiguity' in unqualified
symbols, you might almost say. I certainly grant you that
it leads to troubles every now and then, though.
2. Of late I've been seriously questioning whether anything so
important as the base ought to be allowed to fluctuate. We
certainly pay a big price for that flexibility. Nevertheless,
both this and *READTABLE* do indeed provide creative ways for
modules to screw each other.
3. *READTABLE* is already powerful enough to provide what you need
if only there were a way of suitably modifying a readtable.
4. One of the reasons we can survive at all with *PACKAGE*, etc.
is that good programmers know there is a finite set and they
carefully bind the ones that matter around individual calls to
READ, or around module boundaries, or whatever. To introduce
a new one at this point is the same kind of destabilizing thing
as introducing a new special form. (Of course, since we've recently
introduced some new special forms, this isn't a hard and fast
argument, but it is a moral dilemma we had to contend with when
adding those special forms and I think we should have to wrestle
with it here anyway.)
5. Just because there is precedent for problem doesn't mean we should
invite more problems based on that precedent. You yourself admit
that *PACKAGE* and friends invite problems.
1 and 2 are just my personal thoughts and I don't expect them to
carry any argumentative weight.
4 and 5 are issues I think we can't ignore.
The option of doing 3 is compelling to me. I think this is the past
of least resistance. I think it is just complicated enough that naive
users will not do it accidentally and then run into problems, yet
straightforward enough that no one who needs case preservation will
have any trouble figuring out what to do.
I think someone should therefore instead propose that we introduce some
operation like SET-CHARACTER-CASE-TRANSLATION (or perhaps something more
general like Genera's SET-CHARACTER-TRANSLATION, which I think -- I didn't
look up its documentation recently -- allows you to say that arbitrary
chars are translated to arbitrary others).
∂16-Feb-89 0758 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 16 Feb 89 07:56:58 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06670; 16 Feb 89 15:18 GMT
Date: Thu, 16 Feb 89 15:41:29 GMT
Message-Id: <6347.8902161541@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, cutting.pa@xerox.com
Cc: CL-Cleanup@sail.stanford.edu,
richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
> 3. *READTABLE* is already powerful enough to provide what you need
> if only there were a way of suitably modifying a readtable.
>
> I think someone should therefore instead propose that we introduce some
> operation like SET-CHARACTER-CASE-TRANSLATION (or perhaps something more
> general like Genera's SET-CHARACTER-TRANSLATION, which I think -- I didn't
> look up its documentation recently -- allows you to say that arbitrary
> chars are translated to arbitrary others).
I would be perfectly happy with such a proposal. I am surprised,
though, that my suggestion is as controversial as it seems to be.
Right now I can change the operations of READ in lots of ways, by
setting the input base, by defining macro characters, and so on. I
don't see why a simple thing like case sensitivity is such a problem.
Indeed, you don't really seem to think it is, for you seem willing to
have it done by the read table, just not by a new parameter.
Some of your arguments are against the whole idea of case-sensitivity,
others against the addition of *READ-CASE*, and others against the
admittedly somewhat peculiar interpretation of :UPCASE and :DOWNCASE
(but I think the interpretation of these values for *PRINT-CASE* is
also not what one would immediately expect). This mixture is
confusing. At some times, it seems that you hate every aspect of the
proposal, but at others that all you really dislike is the the
addition of a new parameter (admittedly a problem that is not just
aesthetic) and the particular keyword values I propose.
One reason I proposed a parameter rather than a readtable operation
was that it seemed more consistent with the way the rest of Common
Lisp worked. (And, I suppose, because some other Lisps worked that
way.) BUT, I don't really want to argue this point. Indeed, I now
would say I was wrong.
However, I had to pick one of the many possible proposals as a
starting point, and the addition of a new parameter looked simpler
that trying to handle all the versions of readtable operations.
I tried to at least hint at other possibilities at various
points, but I didn't want to write a complicated proposal that
considered everything until I had some feedback.
As for the issue of case distinctions in code, I did expect that to
be controversial. But I don't want disputes of that sort to doom
a facility that is also useful in applications.
I do not actually find the arguments for using case distinctions in
Lisp code all that important (perhaps because I don't expect to do it
myself), but it is definitely useful for applications to be able to
use READ in a case-sensitive way. The difficulty of doing this has
come up again and again (at least here), and it is difficult to
explain why Common Lisp does not provide this capability in any
reasonable way, especially since it provides much more powerful
things such as character macros.
However, one of my reasons for submitting this proposal was simply to
make the rationale explicit. And there your messages are very
helpful. I didn't try to make every point for and against myself,
because I hoped the discussion would do some of it for me. I don't
think I completely overlooked the points you've raised, but I didn't
try to put them all in the proposal, and we obviously assign them
different weights. Now I'd like to revise and try again. (Well,
actually I'll wait 'till the dust settles a bit.)
Although this issue is in some ways trivial, I do think it is
important.
-- Jeff
∂16-Feb-89 0857 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Feb 89 08:56:50 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 540363; Thu 16-Feb-89 11:54:05 EST
Date: Thu, 16 Feb 89 11:53 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, cutting.pa@xerox.com,
CL-Cleanup@sail.stanford.edu,
richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
In-Reply-To: <6347.8902161541@subnode.aiai.ed.ac.uk>
Message-ID: <890216115342.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 16 Feb 89 15:41:29 GMT
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
... Right now I can change the operations of READ in lots of ways, by
setting the input base, by defining macro characters, and so on. I
don't see why a simple thing like case sensitivity is such a problem. ...
Actually, this makes me all the more certain that the readtable is the
right way to go. The reason is that you can imagine a world in which I
have hacked the readtable to get me case sensitivity but you have bound
*READ-CASE* to ignore case sensitivity. This is something of an invincible
force and an impentrable barrier problem -- two conflicting goals using
orthogonal mechanisms such that it's impossible to weigh their importance
adequately. By forcing us to use the same mechanism, we see that we either
use your readtable or mine, or that both readtables are the same and you've
mucked up mine or I've mucked up yours. This reduces the problem from one
of the system trying to arbitrate a situation it cannot hope to settle fairly
to a simple program bug -- one or the other of us will send nasty mail to
the other and the system won't be caught in the middle.
By the way, as a slightly tangential remark, I think that *READTABLE* is
misnamed. I really think it should be called *SYNTAX*, or perhaps even
*LANGUAGE*. The reason is that the printer needs to be affected in
lockstep when you bind the reader in order to preserve PRINT/READ
consistency. So if I change my backslash character to slash in Symbolics
Common Lisp, the printer must know to write /a rather than \a. Calling
it *SYNTAX* would divorce you from the idea of READ-only effects, since
syntax can address printing as well. Once you study the issue a bit
more, you realize there are other dynamic properties of a language
which it is -also- useful to bind when running programs from one or
the other language which have nothing to do with PRINT/READ. If you
allow them to be bound separately, you get in weird situations where
you have hybrid environments that have `Common Lisp syntax' but
`the Zetalisp package system' but ... Almost never do these things turn
out to be useful. Usually they are the result of binding too few variables
in lockstep. If *SYNTAX* were further generalized to encompass non-
print-read kinds of things, you might call it *LANGUAGE*. By having a
single variable, it would always get bound consistently. (If you really
still wanted a new language, you could make a new object which had the
same blends of things, but you could not do it by accidentally binding
one too few variables.)
... At some times, it seems that you hate every aspect of the
proposal, but at others that all you really dislike is the the
addition of a new parameter (admittedly a problem that is not just
aesthetic) and the particular keyword values I propose.
People are complex entities. They must weigh the realities of the world,
which are rarely black and white. My message may have drifted back and
forth but was intended to expose the basis for my reasoning, which I must
ultimately boil down to a single recommendation. If I choose to say just
my opinion, you'd think me stubbornly dogmatic. At least with the additional
information you know I've given the issue some thought.
... I had to pick one of the many possible proposals as a
starting point ...
I'm glad you did. If you're happy with the readtable solution, I think
there's a good chance you'll come up with something I can endorse.
I thought more about the analogy to adding special forms last night
and decided that the analogy is slightly misaligned -- the real truth
is that the `fixed number of special forms' only affects people writing
code-walkers. Adding special forms isn't so good, but affects only a
few programs. Adding a new variable of this type would break a huge number
of Common Lisp programs because a huge number call READ and because
CL programs are assumed to `act defensively' (bind variables they worry
might be wrong). Since no existing program can have anticipated the need
to defend itself against this `problem,' no program will be ready and
the Cost To Users is (as I said) large. I think this consideration has
to be overriding.
I admit that if we were starting anew, compatibility would not be an
issue and I could not argue against *READ-CASE* on the basis of compatibilty.
But if we were really starting anew, I would argue for *SYNTAX* or
*LANGUAGE* in order to accomodate the bundling of linguistic features
as a unit. And READ-CASE then would be likely be a slot in that structure,
just as it's conceptually a slot in your `frame' for computer languages
in general. And I would argue that you should not set the slot, or any slot,
because changing any named language only gratuitously breaks those programs
which thought they knew what the semantics were at the time when they wrote
them. There's never really any problem about just spawning a new language
because no matter what syntax/semantics you give it, you never break programs
in other languages.
I'll stop here before I start to question why we're changing a single letter
of CLtL in order to produce ANSI CL and to ask why we don't just call the
language we're designing something else so we don't break programs... :-)
∂16-Feb-89 1104 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 16 Feb 89 11:01:58 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09136; 16 Feb 89 18:53 GMT
Date: Thu, 16 Feb 89 18:49:52 GMT
Message-Id: <7024.8902161849@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>
In-Reply-To: Kent M Pitman's message of Wed, 15 Feb 89 16:28 EST
Cc: CL-Cleanup@sail.stanford.edu,
richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
> I appreciate your good intentions in writing this proposal, [...]
It's sometimes difficult to reply to a long message, for the reply may
be long as well, an no-one really wants to read a bunch of long
messages. So I will try to keep this as short as possible.
First, I think we should separate some issues:
0. Lower-case vs. upper-case.
1. Case-sensitivity in code (as a style or convention).
2. Case-sensitivity as an option when reading.
3. The addition of a new parameter vs. an operation on readtables.
4. The particular choice of *READ-CASE*, :UPCASE, and :DOWNCASE.
I, personally, do not want to argue about whether (1) is a good idea.
It's the sort of thing about which people can endlessly disagree. The
same goes for (0). I don't have any particular attachment to (5) and
am willing to revise the proposal or to see an alternative from
someone else. That leaves (2) and (4).
Should Common Lisp support case-sensitive reading?
There are a number of applications that could make good use of the
Common Lisp reader except for one thing: the reader does not preserve
case. I would like to help these applications. In addition,
programmers who wanted to wanted to use case distinctions in code
would find it easier to do so. You can regard this as an application
if you wish: there is a language very like Common Lisp only...
Common Lisp already allows the user to change the meaning of
characters by defining character macros, by changing the base
of numbers, and so on. While some of these may be a bad idea,
character macros (at least) can be defended. So I don't think
any arguments that apply just as well to character macros are
very compelling.
New parameter or readtable operation?
Kent has argued well against the addition of a new parameter.
Any code that thinks it already takes all read parameters into
account would have to change. So there is a potentially high
cost to users.
A readtable operation would involve only an existing parameter,
*READTABLE*. However, if all we want is to set whether the reader is
case-sensitive or not, something that lets us have any character
translated to any other is arguably too powerful. I don't want to
have a long debate about whether or not it's a good thing; and I can
imagine that some people might feel quite strongly that it is not.
Also, it's not a particularly convenient way to change case
sensitivity (though it's not all that hard). However, a read table
operation that just changed case sensitivity seems strange. The
number base isn't part of the readtable, so why should this be?
And should it be a keyword argument to COPY-READTABLE? I wanted
(at least initially) to avoid such questions and to present a
proposal that seemed simpler (think, e.g., of what it would take
to write the test case).
I am willing to go either way, but I would like to know what
people think. I would have presented more options in the initial
proposal, but I think it's best to have one option if we know it's
the only one we really want.
-----
Responses to specific points follow:
> If case is -ever- to be significant, case must be preserved internally.
> [...] CLtL indicates that this is true.
> If case is significant internally, then every symbol must have a
> well-defined internal casing in order to be found.
> An arbitrary choice must be made between whether CAR maps to |CAR| or
> |car|.
I agree.
> Some case had to be chosen. The arbitrary choice made was uppercase.
> Personally I think this was the right choice, but I recognize that others
> would have preferred lower.
The general trend is towards writing code in lower case. The T
sources are now in lower case, Winston and Horn 3e uses lower case.
Both used to be upper. I think it may have been shown that lower case
is easier (for most people?) to read. Still, this is to a large extent
a matter of taste and not something that this proposal would change.
> [...] if you set *PRINT-CASE* globally, you don't interfere with the
> correct operation of libraries that others have written,
That is true, but setting *READTABLE* does interfere with the correct
operation. So this is not something Common Lisp has carefully avoided
so far. Indeed, I think it is a good thing that the reader can be
used to read in other than the standard way, though perhaps not a good
thing that it is controlled by global parameters.
This line of argument would be better if the read table were one of
the arguments to read rather than controlled by a special variable.
> In spite of what I would characterize as superficial criticisms from
> people about Common Lisp and/or *PRINT-CASE*,
The criticism issue is a fairly complex one. Some people make
wild claims about Common Lisp and cite "easy targets" such as FORMAT.
Often there is something reasonable behind the complaints, but it is
often difficult to find it out. With fewer easy targets it would be
easier to get at the real problems, and wild claims would be harder
to make. People would have to think harder.
Anyway, a number of reasonable people who are quite willing to use
Common Lisp have applications in which they could use a case-sensitive
reader. They are often surprised to find that there's no way to do
it.
> Your *READ-CASE* proposal is incomplete because the test case does
> not show the calling of a built-in function.
OK. I'm not sure how much test cases have to cover. There are
certainly other proposals that do not test every consequence.
Anyway, since it's dangerous to set *READ-CASE*, I rebound it
instead, since that is what I think people will do.
> Leaving aside issues of what would out and out break
> if you set *READ-CASE* to :DOWNCASE, you'd end up having to write
> (CAR Zebra)
That one must write CAR is mentioned in the aesthetics.
> A more technically reasonable alternate solution might be to extend
> *PRINT-CASE* to take a sort of alist as a value. Eg, consider:
> ((ZEBRA . "Zebra") :UPCASE)
That seems to address a completely different issue (something about
output rather than input, it appears).
> I am also amenable to the idea of creating a portable way to modify
> the readtable to turn off case translation.
I am also amenable to that idea.
> Point #3 of the Rationale is, as I've discussed, not a problem but a
> feature. It's perhaps not as strongly motivated in the writeup as it
> might be, but I stand by it strongly.
I'm not sure what you mean here. I don't think it's a problem that
Common Lisp has *PRINT-CASE*, but I do think it's a problem that
there's no way to control the way the reader treats case.
> My two counter-suggestions above are intended to
> help clarify the point that I am not objecting to your problem
> description as unreasonable but rather to your solution as overly
> naive.
What I think is most suspect about my proposal is the attempt to
parallel *PRINT-CASE*. I do not think the addition of a new variable
is necessarily unreasonable, since it is in some ways the simplest
solution.
> Also, following directly from my above remarks, your Cost of Users is
> drastically understated.
Very true. I was not thinking clearly.
> The feature is not compatible since the very
> presence of *READ-CASE* would mean that programs would not snap together
> reliably if this variable were ever set. In practice, this would mean
> that any call to READ would have to be surrounded by a binding of
> *READ-CASE* just in case.
I think that's going a bit far. After all, it's not now the case that
every call to READ is surrounded by a binding of *READTABLE*.
> One parting remark, I think the proposal name LIKE-PRINT-CASE is confusing.
> I would have expected that to mean `things typed in get downcased.' Only
> pragmatics would tell me this is ludicrous.
I would have used NEW-PARAMETER (which is also perhaps ambiguous,
since it might mean an argument to PRINT) except that there were
several possible new-parameter proposals.
-- Jeff
∂16-Feb-89 1215 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 16 Feb 89 12:15:29 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA21232; Thu, 16 Feb 89 12:13:52 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA03738; Thu, 16 Feb 89 12:10:25 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA05969; Thu, 16 Feb 89 12:13:18 PST
Message-Id: <8902162013.AA05969@denali.sun.com>
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Cc: Kent M Pitman <KMP@scrc-stony-brook.arpa>
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
In-Reply-To: Your message of Thu, 16 Feb 89 18:49:52 +0000;
<7024.8902161849@subnode.aiai.ed.ac.uk> .
Date: Thu, 16 Feb 89 12:13:17 PST
From: peck@Sun.COM
Some random thoughts on READ-CASE-SENSITIVITY.
First let's remember that we're not asking for more functionality,
in this issue, we're looking for a way to make READ do *less*.
In the naive world, strings would read as they were written,
and, oops, symbols naively interned would choke on mixed case.
Two alternatives have been mentioned so far:
1. Change the code in READ to not coerce to uppercase (controlled somehow)
2. Use *readtable* to produce the new effect.
There is another possible solution:
3. Introduce a new function to provide what you want.
Kent states that the status quo was done so that programs would
be more portable (or portable at all) among uppercase source
and lower or mixed case source files.
Kent further suggests that using *readtable* would be an appropriate way
to avoid upcasing. [if using readtables to control casing behavior is so
straight forward, why was the status quo implemented as a change to READ,
rather that as a change to *readtable*? ;-]
[[no flames please, I answer this for myself three paragraphs down...]]
Plenty of discussion about the danger of reading code when *read-base* or
*readtable* is set inappropriately. Also, plenty of discussion that
PROVIDE/REQUIRE don't port. Really, portable code should come with
its own loader which rebinds reader controls and loads its files as needed.
Dalton states:
>There are a number of applications that could make good use of the
>Common Lisp reader except for one thing: the reader does not preserve
>case. I would like to help these applications. In addition,
> ↑↑↑↑↑↑↑↑↑↑↑
>programmers who wanted to wanted to use case distinctions in code
>would find it easier to do so. You can regard this as an application
>if you wish: there is a language very like Common Lisp only...
I'm all for mixed/lower case (I like Franz's solution) but let's face it:
*** READ is designed for reading programs (symbols, lists, structs, etc). ***
It sounds like you are not primarily concerned with wanting
"to use case distinctions in code". So, READ should not be changed.
Dalton, about these large bodies of code which could use READ, except
for the caseing behavior: can they survive what READ will do with
chars like #\# #\: #\\ #\| #\` #\( #\) when they are read?
If you are not using READ for code or symbol and package rules,
the what do you get from READ? the *readtable*?
To read text you really need to use READ-CHAR or READ-LINE.
Even if READ can be used, is it really a good idea? Do you really want
to cons a symbol for everything that READ would break into a token?
Maybe you should suggest a READ-TOKEN or READ-SYMBOL function
that parses like READ (if your really want that) and returns
a symbol (interned where?) or maybe just a READ-WORD that
does READ-CHAR up to the next whitespace and interns the string?
Given READ-LINE and READ-CHAR and the multiple interpretations of
what and when should you break symbols out of text, why/how should
this be standardized?
[Better Lisp environments come with an Emacs (or whatever), that
is maybe the correct place for text processing Upcase/mixed-case
word parsing, etc.]
Whatever we decide about this, lets make sure it makes sense with the
newly proposed internationalize character operations.
∂16-Feb-89 1241 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 16 Feb 89 12:41:26 PST
Received: from relay2.cs.net by RELAY.CS.NET id as04062; 16 Feb 89 14:41 EST
Received: from draper.com by RELAY.CS.NET id ab10531; 16 Feb 89 14:37 EST
Date: Thu, 16 Feb 89 08:08 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
Re KMP's reply to jeff: Without disagreeing with those arguments, I would
point out that much of the problem Kent finds with the use of *READ-CASE*
applies equally well to *PACKAGE*. (The main difference is that you normally
expect symbols like CAR to be "already around" and therefore not interned in
the "wrong" package - but this is analogous to typing CAR in uppercase under
the proposal.) Users already have to beware of some random piece of code
changing the value of *PACKAGE* and affecting the way symbols get read in.
Is this so different?
Also, the horror of having to type CAR instead of car doesn't bother folks
who are used to UNIX and C.
A similar topic raged on the common-lisp list several years back, as I recall,
with the upshot being that only the franz community wanted or cared about
case sensitivity (or was it forced downcasing?) in the reader, and everyone
else thought it was a bad idea. This may still be true, but (a) Jeff's
proposal seems more well thought out, and (b) UNIX isn't as much of an alien
force as it once was.
∂17-Feb-89 0004 CL-Cleanup-mailer Cleanup Issue Status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Feb 89 00:04:08 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 FEB 89 00:00:42 PST
Date: 16 Feb 89 23:59 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Cleanup Issue Status
Message-ID: <890217-000042-4941@Xerox>
I'm really late on getting this out. Lest I delay any further, I thought
I'd at least send out my (very rough draft) status list. Many of the issues
that were passed with amendments still need someone to produce an updated
version. I'm really swamped and could use some help.
I've not gotten around to listing any of the issues that have been
submitted since the last meeting; I have nearly 200 messages on cleanup &
editorial that I've not sorted out.
Sorry for the delay,
Larry
!
Code:
+ passed
- withdrawn, failed, etc.
* pending, passed but need version as amended, etc.
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
* ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 7, 15-Feb-89
Status: ready for release?
- ALIST-NIL
Version 4, 1-Oct-88
Status: Withdrawn, recommend editorial
- APPEND-ATOM
Synopsis: atom case of APPEND (left out of APPEND-DOTTED)
Version 1, 6-Dec-88, Released 12-Jan-89
Status: withdrawn 18-Jan-89 because APPEND-DOTTED withdrawn
- APPEND-DOTTED
14-JAN-88, Version 5
Status: Passed Nov 88 X3J13, reconsidered & withdrawn Jan 89 X3J13
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
14-NOV-87, Version 7
Status: Passed, 1988?
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ AREF-1D
Version 7, 14-NOV-87
Status: Passed, 1988?
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?
- BACKQUOTE-COMMA-ATSIGN-DOT
Synopsis: `(... ,@x) vs `(... . ,x). Same, different, is error?
Version 1, 22-Dec-88, DRAFT released
Comments: proposals INTERCHANGABLE and DIVERGENT comments not in writeup
Status: Withdrawn, since APPEND-DOTTED withdrawn. Default is IS ERROR
* CLOS-CONDITIONS
Version 3, 9-Oct-88
Comments: should rewrite to make clear that it makes error/signal system
compatible with CLOS but not required, at least at bootstrap time.
Status: pending
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
+ CLOSED-STREAM-OPERATIONS
Version 7, 14-Feb-89
Synopsis: What operations are legal on closed streams?
Comment: amendment bad?
Status: Passed, as amended, Jan 89 X3J13
- COERCE-INCOMPLETE
Synopsis: Extend COERCE to handle default coercions? take optional
FROM-TYPE?
Version 2, 21-Nov-88
Status: withdrawn?
+ COLON-NUMBER
Synopsis: :123 is an error
22-OCT-87, Version 1
Status: Passed, 1988?
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988?
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
* COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
4-SEP-88 Version 2
Status: Passed, 1988?
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89
Status: passed, Jan 89 X3J13
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Status: passed, Jan 89 X3J13
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
+ DECLARE-MACROS
5-FEB-88, Version 3
Status: Passed, 1988?
- DECLARE-TYPE-USER-DEFINED
Synopsis: allow (declare ((signed-byte 8) x y z)) for all type specifiers?
Status: Withdrawn (never submitted)
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
- DEFINITION-DELETE
Synopsis: provide a way to get rid of structures, etc.
Status: not submitted
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Status: Passed, Jan 89 X3J13
Comment: clarify "at variance" in editorial work?
- DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Synopsis: defstruct accessors are proclaimed inline
Version 2, 7-Jan-89, released 10-Jan-89
Status: rejected, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 3, 6-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFVAR-DOCUMENTATION
23-NOV-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INIT-TIME
29-MAR-87, Version 2
Status: Passed, 1988?
+DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988?
- DELETE-FILE-NONEXISTENT
Version 1, 5-Oct-88
Comments: should just signal different errors?
Status: withdrawn
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988?
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
14-FEB-88, Version 2
Status: Passed, 1988?
* DYNAMIC-EXTENT
Version 3, 11-Jan-89
Status: DRAFT, ready for release?
- ELIMINATE-FORCED-CONSING
Synopsis: Add :RECYCLE or :MODIFY to some sequence fns,
Version 3, 31-Aug-88
Status: withdrawn
* ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
value in consistent format across implementations. This makes
them virtually useless. I would like to constrain the values
enough so that implementors knew what to provide as return
values, and provide some examples of intended uses."
Status: need volunteer to submit
* EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Status: Passed with amendments; need correctly amended version:
EQUALP uses EQ for structures and instances
EQUALP descends hash tables, comparing the count and :test,
and comparing keys by :test and values by EQUALP.
* ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88
Status: pending (was CLError)
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
* EXIT-EXTENT
Summary: What happens with non-local exits out of UNWIND-PROTECT cleanup
clauses?
Version 6, 8-Jan-89
Status: postponed; ready for vote March?
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
- FILE-LENGTH-PATHNAME
Synopsis: extend FILE-LENGTH to work on pathnames
Status: not submitted/ withdrawn
* FILE-WRITE-DATE-IF-NOT-EXISTS
Synopsis: What does FILE-WRITE-DATE do if no such file?
Version: no proposal
Status: pending
* FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Status: Accepted TIGHTEN-DEFINITION, with amendment to require that
ARRAY-DIMENSION-LIMIT ≤ MOST-POSITIVE-FIXNUM
TOSS-BIGNUM failed 4 to 12
Need revised version
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988?
+ FLET-IMPLICIT-BLOCK
Version 6 5-JUN-87
Status: Passed, 1988?
- FOLLOW-SYNONYM-STREAM
Status: Not Submitted; lost in STREAM-ACCESS. Withdrawn?
+ FORMAT-ATSIGN-COLON
Version 4 5-JUN-87
Status: Passed, 1988?
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988?
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988?
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988?
- FORMAT-NEGATIVE-PARAMETERS
Synopsis: What does FORMAT do when it gets negative numbers for count?
Version: No proposal
Comment: KMP will incorporate in the list-of-signals part of the signal
proposal?
Status: not submitted
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
- FORMAT-ROUNDING
Synopsis: specify that ~F rounds up
Version 1, 5-Oct-88
Status: withdrawn
* FUNCTION-ARGUMENT-LIST
Synopsis: want way to get argument list
Status: not submitted
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
* FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88
Status: need new version
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ FUNCTION-TYPE
4-SEP-88, Version 12
Status: Passed, 1988
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
* GET-MACRO-CHARACTER-DISPATCHING
Synopsis: What does GET-MACRO-CHARACTER return for dispatching macros?
Status: not submitted
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988?
* HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88
status: awaiting new version
- HASH-TABLE-GC
Synopsis: allow hash tables with GCable keys
Status: no proposal
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
* HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal
- HASH-TABLE-STABILITY
Version 1, 11-Nov-88, Released 12 Dec 88
Comments: superceded HASH-TABLE-KEY-MODIFICATION
Status: Rejected Jan 89 X3J13
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 8 8
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5 ??-MAY-87
Status: Passed, 1988?
* IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Status: tabled
* IN-SYNTAX
Synopsis: like IN-PACKAGE but for readtables
Version 1, 21-Oct-88
Comments: too narrowly focused?
Status: needs new version
- INPUT-STREAM-P-CLOSED
Synopsis: What do INPUT-STREAM-P and OUTPUT-STREAM-P do on closed streams?
Status: not submitted
- INPUT-STREAM-P-EXAMPLE
Synopsis: (input-stream-p (make-broadcast-stream)) is NIL
Version 1, 26-Oct-88
Status: bug report, needs no clarification?
+ KEYWORD-ARGUMENT-NAME-PACKAGE
8-NOV-87, Version 8
Status: Passed, 1988?
- LAMBDA-FORM
Version 4, 22-Nov-88, Released 8-Dec-88
Status: rejected, Jan 89 X3J13
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
- LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION
Synopsis: should LEAST-POSITIVE- and MOST-POSITIVE-XXX-FLOAT
numbers include denormalized ones in those implementations
that admit them?
Status: Not submitted
* LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: tabled
* LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Comments: Don't like (DEFVAR CAR ...) example
14: Like simpler "Redefining any documented
definition on a symbol in the LISP package -- such as variables,
functions, constants, properties and property-lists, etc -- is
undefined, except for the explicitly allowed cases (e.g. dynamic
binding of variables)."
Status: tabled
- LIST-TYPE-SPECIFIER
Synopsis: add a type specifier (LIST NUMBER)
Version 1, 28 Jun 88
Status: withdrawn
* LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled
files
Version 1, 2-Jan-89
Status: need new version?
- LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Comments: same arguments as REQUIRE-PATHNAME-DEFAULTS?
Status: not submitted
MACRO-ENVIRONMENT-EXTENT
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
- MAKE-CONCATENATED-STREAM-EXAMPLE
Synopsis: (read (make-concatenated-stream (make-string-input-stream "1")
(make-string-input-stream "2"))) => 12?
Version 1, 26-Oct-88
Status: withdrawn, no issue (bug report to one implementation)
* MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Comment: Accepted (6 to 11 on first vote, 12 to 4 on second vote), with
amendment
to make the default be undefined (unspecified?), instead of the
incompatible
change originally proposed to make the default by the
implementation-dependent
packages
Status: Passed, need new version as amended
* MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88
Comments: extend to take other keywords? MAKE-STRING should return
simple string always? Interaction with character proposal
Status: awaiting new version
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
* NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comments: Accepted (9 to 7), with amendment to clarify what happens if n is
out of range
Status: need new version as amended
- OUTPUT-STREAM-P-EXAMPLE
Synopsis: Clarify (output-stream-p (make-concatenated-stream)) is NIL?
Version 1, 26-Oct-88
Comment: already clear; just bug report for one implementation
* PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment that the forbidden property indicators
are
external symbols in all packages defined by this standard plus all
symbols accessible in the USER package or in packages defined by
the user.
Status: need writeup as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Comments: Minor glitches? Remove the description of "correctable" error to
be signalled and
handled.
Status: passed, Jan 89 X3J13
* PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: Accepted MORE-PERMISSIVE (v2), as amended
----- Moon 21-Jan-89 (Version 2) -----
MORE-PERMISSIVE is like PERMISSIVE except that the four
functions
identified by CLtL as "package structure accessors" that don't
allow
names are changed to allow names.
Amendments made at the meeting added DELETE-PACKAGE and
DEFPACKAGE
to the list of functions and removed the paragraph beginning
with the words "If IN-PACKAGE...".
Status: need new version as amended
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?
* PATHNAME-COMPONENT-CASE
Synopsis: allow ALL UPPER CASE to mean "use the 'right' case
Comments: lots of heat?
Status: => "pathname" committee
* PATHNAME-EXTENSIONS
Synopsis: allow a way of telling whether a pathname is a pattern, a "funny"
file
Comments: necessary in standard?
Status: => "pathname" committee
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: need new version
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988?
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988?
* PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: need new version
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version
- PATHNAME-TYPE-UNSPECIFIC
Version 1 27-Jun-88, Released 7 Oct 88
Comments: may be subsumed
Status: withdrawn; superceded by PATHNAME-UNSPECIFIC-COMPONENT
* PATHNAME-UNSPECIFIC-COMPONENT
Version 1, 29-Dec-88, Released 12-Jan-89
Synopsis: More extensions to :UNSPECIFIC
Comment: Accepted (14 to 4), with amendments to allow any field to be
:UNSPECIFIC including host and name, and to say that "To use
:UNSPECIFIC in an operating system for which it does not make
sense, the results are undefined."
----- Moon 21-Jan-89 -----
RWK pointed out that :UNSPECIFIC has two meanings: the component
is omitted in this particular pathname (type in Unix) or the
component is not meaningful for this system (version in Unix).
Cross-host defaulting needs to treat those differently, so
:UNSPECIFIC can't get into a field where it is not allowed.
In the end RWK suggested people should vote for the proposal
anyway, as it was a net improvement.
Status: needs new version as amended
* PATHNAME-WILD
Version 2, 6-Oct-88
Synopsis: Portable way to ask about "wildcard" pathnames?
Comments: consistent with PATHNAME-COMPONENT-CASE?
Status: => "pathname" committee
+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted
* PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment to apply to methods on PRINT-OBJECT in
addition to :PRINT-FUNCTION options
Status: need new version as amended
* PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: change "Clarify" => "Define"
- Good idea, but insufficient experience implementing&using.
- OK in principle; want discussion to ensure talking about same thing.
- No fundamental complaint, but more experience needed before standard.
- Define the status of unproclaimed free variables.
Presumably, they are an error; compilers should issue a warning.
- I don't believe in separate "dynamic" environment, don't believe it
makes sense to support rapid access to Globals on stock hardware,
and don't understand what Scheme practices don't work in Common Lisp.
- 8: If it can be implemented easily then I'm for it.
- 14: If it is clearly spelled out that it is
an error to make a dynamic binding of a proclaimed lexical variable;
we could not find such a statement in the proposal.
Status: tabled
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988?
+ RANGE-OF-COUNT-KEYWORD
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
- READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Status: Not submitted
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
* REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 2, 08-Jan-89
Comment: lengthy dissent; discussion? coercion for comparitor?
Status: need new version
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988?
* REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 2, 29-Oct-87, Released 8-Oct-88
Version 4, 29-Nov-88, Released 12-Jan-89
Status: There was a straw vote in favor of this, then BarMar was appointed
to make some amendments and put it on the letter ballot. I
think the
amendments are to tighten up NCONC and remove NBUTLAST, NSUBSTx,
and NSUBSTITUTEx.
* REMF-MULTIPLE
Synopsis: What does REMF do if it sees more than one INDICATOR?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: newly released
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
- REST-LIST-EXTENT
Synopsis: allow way to declare dynamic extent &REST
Status: incorporated in issue DYNAMIC-EXTENT
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Version 6, 06-Oct-88, Released 11-Jan-89
Comments: New version scales down previously rejected version
Status: Version 6 rejected Jan 89 X3J13
* SETF-FUNCTION-VS-MACRO, SETF-PLACES
SETF-FUNCTION-VS-MACRO Version 3, 4-Nov-87, Released Nov 87
Vote: 1y3y4n5n6y7i8i9y10n11y12y13n14i SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
SETF-PLACES Version 1, 11-Nov-88, Released 9-Dec-88
Vote: 1n3n4i5n6i7y8n9n10n11n12n13n14y SETF-PLACES:ADD-SETF-FUNCTIONS
Comments: premature to vote on this issue
want unified issue
7: If SETF-PLACES:ADD-SETF-FUNCTIONS fails.
other options?
8: SFVM:SF much better than before. What about
(defmacro (setf name) ?) Yes if nothing better comes along.
SP:ASF would require code to have ugly #.
12: I don't think it's possible to define a version UNDERLYING-NAME
that returns a symbol and meets all the requirements
13: Not happy with either. First seems nicer but complicates
semantics. second looks like desperate attempt to avoid first.
14: could live with either, SFVM:SF fails to address necessary
issues of cleanup for CLOS document
Status: vote separate?
* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 1, 5-Dec-88
Status: awaiting new version
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
* SINGLE-FLOAT-NON-PORTABLE
Synopsis: remove SINGLE-FLOAT, DOUBLE-FLOAT a la FIXNUM?
Status: Not submitted
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
SPECIAL-VARIABLE-TEST
Synopsis: Add SPECIAL-VARIABLE-P?
Version 2, 31-May-88
Status: "On hold pending SYNTACTIC-ENVIRONMENT-ACCESS"
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* STANDARD-VALUE
Synopsis: user can say binding is "temporary"
Version 1, 21-Oct-88
Comments: not worth trying to standardize now?
Status: ready for release?
* STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Comments: Passed, Jan 89.
Verbally this was explained to mean that the body of the STEP would
not be stepped when compiled, but if it just happened to call an
interpreted function, that function would get stepped. Also the
word "evaluation" in that sentence was amended to "computation."
Status: need new version as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
* STREAM-CAPABILITIES
Version 1, 7/5/88
Synopsis: SAME-SOURCE-P, SAME-DESTINATION-P, etc
Status: awaiting new version, from "pathname/file" committee?
* STREAM-DEFINITION-BY-USER
Synopsis: Want user-definable stream types.
Status: not submitted
* STREAM-ELEMENT-TYPE-EXAMPLES
Version 1, 26-Oct-88
Synopsis: clarify STREAM-ELEMENT-TYPE may return different values?
Status: editorial? Need new proposal?
- STREAM-INFO
Version 6, 30-Nov-88, Released 9 dec 88
Status: Rejected, Jan 89 X3J13
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
* SUBTYPEP-ENVIRONMENT
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* SYMBOL-MACROFLET
Version 1, 30 Sep 88
Synopsis: Add SYMBOL-MACROFLET gives lexical function expansion
Status: need new version
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-SEMANTICS
Version 5, 30-Nov-88, Released 9 Dec 88
Status: Passed, Jan 89 X3J13
* TAGBODY-CONTENTS
Version 5, 9-Dec-88, Released 9 Dec 88
Comments: "good that this failed, but we still need a clarification"
Status: Failed, Jan 89 X3J13
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
* TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Comments: passed, Jan 89 X3J13 FLUSH-ALL, amended to deprecate instead of
removing
Status: Need new version as amended.
* THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: tabled
- TRACE-ERROR
Synopsis: TRACE should signal errors if it doesn't understand
Version 1, 20-Jun-88
Comments: is this a cleanup?
Status: withdrawn
- TRACE-FUNCTION-ONLY
Synopsis: extend TRACE to handle other specs
Comment: we don't like it
Status: withdrawn
* TRUENAME-SYNTAX-ONLY
Version 1, 12-Sep-88
Synopsis: when does TRUENAME perform checking?
Comments: other options? leave more vague? Other questions?
Status: need new version => "pathname" committee
+* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments to include RANDOM-STATE, add the
requirement
that TYPE-OF is always a subtype of CLASS-OF, and say "for all
objects
for which CLASS-OF returns a class with a proper name, TYPE-OF
returns
that proper name".
Status: need new version as amended
* TYPE-SPECIFIER-PREDICATE
Synopsis: "Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time."
Comments: considerable discussion on common lisp mailing list.
Status: Not yet submitted
* UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: Lumping SLOT-UNBOUND in with unbound special variables was a
mistake,
as SLOT-UNBOUND is an extension mechanism, not only a safety
checking
mechanism. Also there were some wording problems. Gabriel and
Gregor
are to submit a revised proposal.
Status: pending
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988?
----- End Forwarded Messages -----
∂17-Feb-89 1031 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 17 Feb 89 10:30:30 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09986; 17 Feb 89 18:07 GMT
Date: Fri, 17 Feb 89 18:04:32 GMT
Message-Id: <9819.8902171804@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: peck@sun.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: peck@com.sun's message of Thu, 16 Feb 89 12:13:17 PST
Cc: Kent M Pitman <KMP@scrc-stony-brook.arpa>
> I'm all for mixed/lower case (I like Franz's solution)
But it's hard to make their change over a single call to read.
> but let's face it:
> *** READ is designed for reading programs (symbols, lists, structs, etc).
> *** It sounds like you are not primarily concerned with wanting
> "to use case distinctions in code". So, READ should not be changed.
READ is not just for reading programs, it is for reading data too.
Lists, symbols, etc. are used outside of source code, after all.
Is this really a controversial point?
The whole readtable mechanism is there so that the behavior of
READ can be modified. And it is not unusual for READ to be used
to parse things that are not standard-syntax Common Lisp source
code.
> Dalton, about these large bodies of code which could use READ, except
> for the casing behavior: can they survive what READ will do with
> chars like #\# #\: #\\ #\| #\` #\( #\) when they are read?
Well, I don't know about "large bodies of code". But certainly
a number of people just here at Edinburgh have wanted to use READ,
but case-sensitive. They have wanted to read expressions that
were sufficiently like Lisp's that a good way to read them was
to modify the readtable a bit. But they also wanted to preserve
case distinctions.
The reason they can't "use READ" is that the readtable mechanism,
and the other ways to affect READ's behavior, still fall short.
You are right to note that it is difficult to change the behavior of
#\: in certain ways, and that one might want to do so. This can be a
pain (though I'm sure there's a good reason for it somewhere), but
most of the changes one might want to make can be done by defining
it as a macro.
(BTW, if anyone wonders, the none of the critical comments I
quoted before the start of the proposal were from Edinburgh.)
> If you are not using READ for code or symbol and package rules,
> the what do you get from READ? the *readtable*?
The read base too.
> To read text you really need to use READ-CHAR or READ-LINE.
I agree completely.
> Even if READ can be used, is it really a good idea? Do you really want
> to cons a symbol for everything that READ would break into a token?
Sometimes a symbol is exactly what I want. Symbols are a useful,
after all.
> Maybe you should suggest a READ-TOKEN or READ-SYMBOL function
> that parses like READ (if your really want that) and returns
> a symbol (interned where?) or maybe just a READ-WORD that
> does READ-CHAR up to the next whitespace and interns the string?
Some Lisps do have something like READ-TOKEN, and it can be useful;
but in these Lisps, it's essentially part of READ that happens to be
available separately. And Common Lisp has PARSE-INTEGER.
But sometimes, I actually want to read lists and have case-sensitivity
set. Really. (Maybe I want to read Franz Lisp code, say.)
> Given READ-LINE and READ-CHAR and the multiple interpretations of
> what and when should you break symbols out of text, why/how should
> this be standardized?
Why should the readtable be modifiable at all? Why should I be
able to define character macros? SET-SYNTAX-FROM-CHAR?
-- Jeff
∂17-Feb-89 1049 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 17 Feb 89 10:48:57 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA04129; Fri, 17 Feb 89 13:47:30 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA00492; Fri, 17 Feb 89 13:45:33 EST
Message-Id: <8902171845.AA00492@mist.>
To: Jeff Dalton <"jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK"@multimax.encore.com>
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
In-Reply-To: Your message of Fri, 17 Feb 89 18:04:32 +0000.
<9819.8902171804@subnode.aiai.ed.ac.uk>
Date: Fri, 17 Feb 89 13:45:31 EST
From: Dan L. Pierson <pierson@mist.encore.com>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: peck@sun.com, CL-Cleanup@sail.stanford.edu
> but let's face it:
> *** READ is designed for reading programs (symbols, lists, structs, etc).
> *** It sounds like you are not primarily concerned with wanting
> "to use case distinctions in code". So, READ should not be changed.
READ is not just for reading programs, it is for reading data too.
Lists, symbols, etc. are used outside of source code, after all.
Is this really a controversial point?
I don't think so at all. The following is from page 365 of CLtL:
"The user is encouraged to turn off most macro characters, turn others
into simgle-character-object-macros, and then use READ purely as a
lexical analyzer on top of which to build a parser. It is
unnecesary, however, to cater to more complex lexical analysis or
parsing than that needed for Common Lisp."
The intent that READ be useful as a lexer for data or embedded
languages is clear. It's also clear that you're asking for an
extension to the lexer's power that is not required for Common Lisp.
I think that it is a reasonable and useful extension if properly
defined.
You can put me down as likely to support a readtable-based case
control extension, however Peck's point that such an extension must
not conflict with the new character proposal is important.
∂20-Feb-89 0944 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Feb 89 09:43:21 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa04231; 20 Feb 89 17:27 GMT
Date: Mon, 20 Feb 89 17:25:45 GMT
Message-Id: <13322.8902201725@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: pierson <@multimax.encore.com:pierson@mist.encore.com>
Cc: CL-Cleanup@sail.stanford.edu, KMP@scrc-stony-brook.arpa
> The intent that READ be useful as a lexer for data or embedded
> languages is clear. It's also clear that you're asking for an
> extension to the lexer's power that is not required for Common Lisp.
Sure, but character macros aren't required for reading standard-syntax
Common Lisp either.
> I think that it is a reasonable and useful extension if properly
> defined.
Thanks.
> You can put me down as likely to support a readtable-based case
> control extension, however Peck's point that such an extension must
> not conflict with the new character proposal is important.
Hummm. I don't think it should be hard to be compatible. Automatic
case conversion seems more likely to run into trouble when there are
lots of different character sets (some, presumably, without a notion
of case).
But it's nontrivial to design something of this sort. The options seem
to be:
* some way just to turn case concersion on and off
* a way to specify a conversion for every character
(normally, some would be converted to upper case)
[I can imagine lots of objections to this since
it would make readtables bigger, it would have to
say what happens when one of the characters is
defined as a macro, etc.]
* define some way for character macro functions to return
a substitute character (or characters?).
* [maybe] specify an alternative character set that doesn't
have case conversion.
Any preferences?
-- Jeff
∂21-Feb-89 1501 CL-Cleanup-mailer Issue IGNORE-VARIABLE, v1
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 15:01:10 PST
Date: Sun 19 Feb 89 15:42:05-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue IGNORE-VARIABLE, v1
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim%ECLA@ECLC.USC.EDU
Message-ID: <12472021827.5.IIM@ECLA.USC.EDU>
In the discussion leading up to this issue being proposed, and in the proposal
itself, there have been a number of comments about it being an error to have a
duplicated name in a binding list. I'm not trying to claim that doing so is a
good idea, but I've never been able to find anything in CLtL that says doing so
is wrong. Also, I believe that the results are actually well defined for
sequential binding forms (though not for parallel binding forms). If CLtL does
say something about this, would somebody please point it out to me?
kab
-------
∂21-Feb-89 1501 Common-Lisp-Object-System-mailer Issue CONSTANT-COMPILABLE-TYPES
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 15:01:51 PST
Date: Sun 19 Feb 89 15:48:59-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue CONSTANT-COMPILABLE-TYPES
To: JonL@LUCID.COM, sandra%defun@CS.UTAH.EDU
cc: Moon@SCRC-STONY-BROOK.ARPA, iim%ECLA@ECLC.USC.EDU,
cl-cleanup@SAIL.STANFORD.EDU, cl-compiler@SAIL.STANFORD.EDU,
common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <12472023082.5.IIM@ECLA.USC.EDU>
The message that prompted this response was sent only to cl-compiler. Since my
response touches on issues of more general interest, I've included cl-cleanup
and common-lisp-object-system as well. Appologies in advance -- this turned
out to be a bit of a tirade.
> Date: Tue, 31 Jan 89 05:05:58 PST
> From: Jon L White <jonl@lucid.com>
>
> > I disagree with the idea of changing the handling for structures.
> > Introducing the LOAD-OBJECTS protocol for standard-class instances is fine,
> > but structures have been part of the language for a while already and I
> > don't see any need to change their handling in an incompatible way. If
> > people find that the default handling of structures is not sufficient for
> > their needs, that's probably a sign that they really need to use the more
> > complex protocol for standard-class objects instead.
>
> I very much agree with what you say here. Unfortunately, not enough
> people objected at the right time -- when the vote on 88-002R was being
> taken -- and this "trojan horse" sneaked in to destroy the defstruct
> house. [in fact, I wonder how many people actualy read 88-002R before
> voting on it?] It's possible that changing the default defstructs to be
> CLOS instances will make it smoother for PCL transition; but I don't see
> how the incompatible changes to the :PRINT-FUNCTION, :COPIER, and
> EQUALP treatment on defstructs helps anyone.
>
> ...
>
> Unfortunately, the EQUAL-STRUCTURE amendment that passed at the Hawaii
> meeting retracted this very useful action of EQUALP on defstructs, and
> rendered it useless again. Hopefully, the final version of the LOAD-
> OBJECTS proposal will specify a more useful default behaviour (e.g.,
> "just like the old CLtL behaviour"?), but note it this will have to
> amend the already-passed EQUAL-STRUCTURE proposal.
>
> -- JonL --
I wish to strongly disagree with almost everything said above. There is a
fundamental assumption being made, namely that structures are second-class
citizens in the CLOS world. This is most clearly expressed by the statement
"If people find that the default handling of structures is not sufficient for
their needs, that's probably a sign that they really need to use the more
complex protocol for standard-class objects instead."
This is terrible! Awful! Totally wrong!
Structures have certain restrictions (single inheritance, don't support
CHANGE-CLASS, ...) in exchange for potentially very efficient access. When
deciding whether to implement a data structure using STRUCTURE-CLASS vs
STANDARD-CLASS, the question a programmer should be asking is "does this class
need multiple inheritance ...", not "am I ever going to need to dump one of
these things, or compare two of them using EQUALP, or ...".
Moon keeps pointing out that only the programmers who define/use a class can
know how to properly copy, dump, test for equality (whatever equality means),
&etc. Unfortunately, under strong pressure from some people he occasionally
sounds like he is willing to cave in on this point in the case of structures.
Well I won't. Removing structure objects from these kinds of protocols and
instead giving them trivial component-wise functionality is utter nonsense. By
all means we should give the programmer mechanisms to help him specify that
kind of behavior if that is what he wants. But it must be a concious decision,
not a default behavior! (As an aside, if it were up to me, the default copier
option for defstruct would be Nil.)
With regard to the EQUAL-STRUCTURE amendment that passed at the Hawaii meeting,
I insisted on EQ for structures because I firmly believe that is the right
default. I would still like to see a proposal to make EQUALP a generic
function; unfortunately, the group who said they would make such a proposal
have not done so. I was thinking about making such a proposal myself, but I've
been having trouble with the specification of the hash function, due to some
ideas I've been working on with regard to hash-table implementations.
kab
-------
∂22-Feb-89 1037 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 22 Feb 89 10:36:05 PST
Received: by ti.com id AA04862; Wed, 22 Feb 89 12:34:27 CST
Received: from Kelvin by tilde id AA18010; Wed, 22 Feb 89 12:26:38 CST
Message-Id: <2813163955-1290904@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 22 Feb 89 12:25:55 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Cc: pierson <@multimax.encore.com:pierson@mist.encore.com>,
KMP@scrc-stony-brook.arpa, CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
In-Reply-To: Msg of Mon, 20 Feb 89 17:25:45 GMT from Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> But it's nontrivial to design something of this sort. The options seem
> to be:
>
> * some way just to turn case concersion on and off
> * a way to specify a conversion for every character
> (normally, some would be converted to upper case)
> [I can imagine lots of objections to this since
> it would make readtables bigger, it would have to
> say what happens when one of the characters is
> defined as a macro, etc.]
> * define some way for character macro functions to return
> a substitute character (or characters?).
> * [maybe] specify an alternative character set that doesn't
> have case conversion.
>
> Any preferences?
I notice that our reader calls CHAR-UPCASE on characters which the read
table defines as possible constituents of a symbol name. Suppose that
instead of a hard-coded call to CHAR-UPCASE, it FUNCALLed a function
contained in the read table, with #'CHAR-UPCASE being the initial value
in the standard read table. That would be a very simple change, but would
give you all the flexibility you might want. The only drawback is that it
could slow the reader down, since our call to CHAR-UPCASE is actually
expanded inline now.
I like the idea of doing things like this as keyword arguments to
COPY-READTABLE, both to avoid inventing new function names and to protect
the standard readtable from alteration. For example:
(DEFPARAMETER *CASE-SENSITIVE-READTABLE*
(COPY-READTABLE *READTABLE* NIL
:SYMBOL-CHAR-TRANSLATION #'IDENTITY))
∂22-Feb-89 1117 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Feb 89 11:16:56 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 543681; Wed 22-Feb-89 14:13:26 EST
Date: Wed, 22 Feb 89 14:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: Gray@DSG.CSC.TI.COM
cc: jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <2813163955-1290904@Kelvin>
Message-ID: <890222141309.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 22 Feb 89 12:25:55 CST
From: David N Gray <Gray@DSG.csc.ti.com>
... Suppose ... it FUNCALLed a function contained in the read table ...
... (COPY-READTABLE *READTABLE* NIL :SYMBOL-CHAR-TRANSLATION ...) ...
I would support such a proposal.
However, I would prefer to see CHARACTER spelled out. This won't be used
often enough to justify abbreviation. Also, I'm not sure that the `SYMBOL'
part of the name is warranted or even a good idea. For example, this
option might control whether you had to write #\Control-\a or could get
away with #\Control-a. Obviously, that's a matter to be decided by the
Characters committee, but if we choose an overly specific name, we'll make
it harder for them to explain. Symbolics has used the function name
SET-CHARACTER-TRANSLATION for a while and to my knowledge no one has
complained that it did not affect (for example) strings. As such, I'd prefer
(COPY-READTABLE *READTABLE* NIL :CHARACTER-TRANSLATION ...)
Providing no way to modify a readtable's character translation function
would avoid the problem of people modifying the standard readtable, but
it would probably also be a nuisance in other situations. My vote would be
for adding a setf-able function READTABLE-CHARACTER-TRANSLATION as well.
Hope this info is helpful.
∂23-Feb-89 1412 CL-Cleanup-mailer Potential issue: MACRO-SPECIAL-FORMS
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 23 Feb 89 14:10:39 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa11723; 23 Feb 89 22:00 GMT
Date: Thu, 23 Feb 89 22:00:42 GMT
Message-Id: <25126.8902232200@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Potential issue: MACRO-SPECIAL-FORMS
To: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
There's a problem that's been bothering me from time-to-time, and
I would like to have it cleared up one way or another. I've actually
mentioned it several times in the context of other issues, but it
never caught on.
I won't put it in official issue format yet, but I am certainly
willing to do so. One problem is that I'm not sure whether the right
forum is Cleanup or Compiler.
Problem:
On page 57, CLtL explains that the list of special forms is kept small
"because any program-analyzing program must have special knowledge
about every type of special form." It goes on to say "Such a program
needs no special knowledge about macros because it is simple to expand
the macro and operate on the resulting expansion."
Indeed, although an implementation is permitted to implement as a
special form any construct described by CLtL as a macro, it is
required to provide "an equivalent macro definition" [also p 57].
However, the implementation note on page 58 explicitly allows the
macro definition to produce an expansion that contains implementation-
dependent special forms, thus making the requirement for an equivalent
macro an empty one.
Consequently, program-analyzing programs are not promised anything of
value.
Proposal:
Remove the permission granted by the implementation note on page 57.
Require that the macro expansion of any construct described as a macro
in Common Lisp not contain any implementation-specific special forms.
A secondary problem:
The implementation note on page 58 claims "there is no problem
with a macro expansion containing calls to implementation-dependent
functions."
Unfortunately, that is not quite true. For example, a special form
(sf . args) might expand to (do-an-sf '(sf . args)), where do-an-sf
is an implementation-dependent function. Such functions are
essentially special forms in disguise.
A program-analyzing program learns nothing of value from such an
expansion.
Not quite a Proposal:
This one is harder, because it is difficult (and perhaps impossible?)
to precisely characterize the class of acceptable functions.
The basic goal is that the intent of the macro definition should be
evident in the expansion. Subexpressions of the macro call that are
identified syntactically as forms should appear as forms in the
expansion, variables should appear as variables, and so on. But we
can't say they must appear only as forms, variables, and so on; so
it's not clear that the goal is an attainable one. There are
presumably other problems as well.
Consequences of non-adoption:
We would have to say that program-analyzing programs potentially
require (and therefore, to be portable, require) special knowledge
about every construct described as a special form or as a macro
in the definition of Common Lisp.
I would like to eliminate the first problem even if we can't
handle the second.
-- Jeff
∂23-Feb-89 1446 CL-Compiler-mailer Potential issue: MACRO-SPECIAL-FORMS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Feb 89 14:45:51 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 544726; Thu 23-Feb-89 17:43:20 EST
Date: Thu, 23 Feb 89 17:43 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Potential issue: MACRO-SPECIAL-FORMS
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <25126.8902232200@subnode.aiai.ed.ac.uk>
Message-ID: <890223174301.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 23 Feb 89 22:00:42 GMT
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
...
The implementation note on page 58 claims "there is no problem
with a macro expansion containing calls to implementation-dependent
functions."
Unfortunately, that is not quite true. For example, a special form
(sf . args) might expand to (do-an-sf '(sf . args)), where do-an-sf
is an implementation-dependent function. Such functions are
essentially special forms in disguise.
A program-analyzing program learns nothing of value from such an
expansion.
...
This part is not true and weakens your earlier point (which I think is
well-taken). For example, the implementation of Flavors used by Cloe
uses a code-walker to implement SYMBOL-MACROLET and that code-walker is
written entirely in portable Common Lisp. What is important to that
code walker (and a whole class of code walkers like it) is that it know
what parts of something are `evaluated normally,' what parts are
`evaluated specially,' and what parts are `not evaluated.' For example,
if UNWIND-PROTECT were not a standard special form but was added by some
implementation with a macroexpander that turned
(UNWIND-PROTECT (FOO) (BAR))
into
(SI::UNWIND-PROTECT-FUNCTION #'(LAMBDA () (FOO))
#'(LAMBDA () (BAR)))
this would be fine. While you're right when you say I don't "learn" anything
from examining the latter form, you're wrong when you fail to observe that
I can `walk' the latter form reliably, while I cannot walk the former.
The reason this is so is because no function in Common Lisp is prohibited
from doing magic things that no user could ever possibly hope to write.
That shouldn't be so surprising. After all, it's not just my function above
that has this property, but also other usually-seen-as-ordinary functions
like OPEN or CAR. I can't write them in Common Lisp either, after all.
Certainly there are applications that need to have a deeper understanding
of what special forms do, but there's really no hope for such applications.
Indeed, such applications probably have to have specialized knowledge about
DO as well -- and cannot even depend on its macro expander to provide "insight".
...
I would like to eliminate the first problem even if we can't
handle the second.
...
I suggest that to do this you should drop the second cause so that arguments
against it don't end up detracting from the first.
By the way, in considering the alternatives, please keep in mind that another
possible solution (besides disallowing macros expanding into implementation-specific
special forms) is to define a code-walker interface and facility for extending same
so that extending the language to have new special forms doesn't cause a breakdown
in the ability to do code-walking. I think it's reasonable to describe this as
beyond the scope of what we have time or resources to do at this point, but I
wouldn't want mention of the option to be omitted altogether.
∂23-Feb-89 1502 CL-Cleanup-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Feb 89 15:02:16 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA27356; Thu, 23 Feb 89 16:00:20 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA10426; Thu, 23 Feb 89 16:00:18 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902232300.AA10426@defun.utah.edu>
Date: Thu, 23 Feb 89 16:00:17 MST
Subject: Re: Potential issue: MACRO-SPECIAL-FORMS
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Thu, 23 Feb 89 22:00:42 GMT
I've been burned by this problem more than once myself. A few
additional observations:
I just recently ran into a problem with Lucid Lisp expanding things
like DEFUN into something that included (FUNCTION (NAMED-LAMBDA ...)).
In other words, it's a valid Common Lisp special form but not valid
Common Lisp syntax for that form. Perhaps a better restriction than
"macros must not expand into implementation-dependent special forms"
would be "macros must expand into code which has Common Lisp syntax".
Once I ran into a problem in VaxLisp where one of the multiple value
macros was treated as a special form by the compiler. It
macroexpanded into some really terrible code and I was getting a
noticible performance hit by having my codewalker just blindly
expanding it. Even though the macro definition was semantically
correct, I ended up adding a whole bunch of macros to the list of
things my codewalker treated as "special forms". I suspect that other
implementations do similar things -- I know my A-Lisp compiler also
treated some of the multiple value macros specially as well.
It ought to be OK for things that are documented as special forms to be
implemented as macros that expand into other implementation-dependent
special forms, since code analyzers are expected to have special
knowledge about them instead of using the macro expansion.
-Sandra
-------
∂23-Feb-89 1525 CL-Compiler-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Feb 89 15:25:25 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 544794; Thu 23-Feb-89 18:22:53 EST
Date: Thu, 23 Feb 89 18:22 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Potential issue: MACRO-SPECIAL-FORMS
To: sandra%defun@cs.utah.edu
cc: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK,
cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <8902232300.AA10426@defun.utah.edu>
Message-ID: <890223182235.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 23 Feb 89 16:00:17 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
...
Once I ran into a problem in VaxLisp where one of the multiple value
macros was treated as a special form by the compiler. It
macroexpanded into some really terrible code and I was getting a
noticible performance hit by having my codewalker just blindly
expanding it. Even though the macro definition was semantically
correct, I ended up adding a whole bunch of macros to the list of
things my codewalker treated as "special forms". I suspect that other
implementations do similar things -- I know my A-Lisp compiler also
treated some of the multiple value macros specially as well.
Just for the record, this is something that I had worried about with the
Cloe Flavors code walker running under Symbolics Genera, but I found
that the Genera compiler had optimizers for many of the scary-looking
idioms that these macros produced, so the compiled code was identical
regardless of whether I compiled the expanded or unexpanded expression.
I have to say that this is as it should be from a `reasonable compiler'
anyway since if there are two seemingly equivalent ways to do something
and the language spec itself does not suggest that one is likely to be
more efficient than the other, the programmer should not have to fear that
just because he didn't say the right incantation, he won't get efficient
code.
...
It ought to be OK for things that are documented as special forms to be
implemented as macros that expand into other implementation-dependent
special forms, since code analyzers are expected to have special
knowledge about them instead of using the macro expansion.
This is a very good point. However, if it were to become accepted
theory, though, it should be explicitly stated. It affects whether I do
a MACROEXPAND-1 or a MACROEXPAND after the call to SPECIAL-FORM-P.
Normally I consider it safe to do either -- and slightly less cumbersome
to do the latter. However, your remark suggests that I might be safer
doing the former.
∂24-Feb-89 0157 Common-Lisp-Object-System-mailer Issue CONSTANT-COMPILABLE-TYPES
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 Feb 89 01:57:23 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01286g; Fri, 24 Feb 89 01:43:50 PST
Received: by bhopal id AA19679g; Fri, 24 Feb 89 01:46:12 PST
Date: Fri, 24 Feb 89 01:46:12 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8902240946.AA19679@bhopal>
To: IIM%ECLA@ECLC.USC.EDU
Cc: sandra%defun@CS.UTAH.EDU, Moon@SCRC-STONY-BROOK.ARPA,
iim%ECLA@ECLC.USC.EDU, cl-cleanup@SAIL.STANFORD.EDU,
cl-compiler@SAIL.STANFORD.EDU,
common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: Kim A. Barrett's message of Sun 19 Feb 89 15:48:59-PST <12472023082.5.IIM@ECLA.USC.EDU>
Subject: Issue CONSTANT-COMPILABLE-TYPES
re: ... only the programmers who define/use a class can
know how to properly copy, dump, test for equality (whatever equality
means), &etc. ... Removing structure objects from these kinds of
protocols and instead giving them trivial component-wise functionality
is utter nonsense. By all means we should give the programmer mechanisms
to help him specify that kind of behavior if that is what he wants. But
it must be a concious decision, not a default behavior! (As an aside, if
it were up to me, the default copier option for defstruct would be Nil.)
Kim, don't you have something turned around here? Previous mail
referred to CLtL p81 to show that defstruct instances should be
descended componentwise by EQUALP. This is not a statement about
classes in general -- just about structure-class, and its historic
meaning under EQUALP. Thus the Hawaii amendment was an *incompatible*
change (which has already raised some question in Lucid's customer land!).
This incompatible change unfortunately does nothing at all towards
supplying the "mechanisms" you call for, and in fact breaks some existing
code (in a very inscrutable way).
Given the failure to make EQUALP generic, wouldn't it be far better
to leave it alone and not make backwards-incompatible changes which
do no one any good?
-- JonL --
∂24-Feb-89 1446 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 24 Feb 89 14:45:40 PST
Received: from fafnir.think.com by Think.COM; Fri, 24 Feb 89 17:41:46 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 24 Feb 89 17:39:54 EST
Received: by verdi.think.com; Fri, 24 Feb 89 17:40:25 EST
Date: Fri, 24 Feb 89 17:40:25 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902242240.AA10382@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: PRETTY-PRINT-INTERFACE
Issue: PRETTY-PRINT-INTERFACE
References: Description of XP by Dick Waters (attached)
*PRINT-PRETTY* (CLtL p. 371)
WRITE (CLtL p. 382)
PPRINT (CLtL p. 383)
FORMAT (CLtL pp. 385-407)
FORMAT ~T directive (CLtL pp. 398-399)
FORMAT ~< directive (CLtL pp. 404-406)
Related issues:
Category: CLARIFICATION CHANGE ADDITION
Edit history: Version 1, 24-Feb-89 by Steele
Problem description:
At present Common Lisp provides no specification whatsoever of how
pretty-printing is to be accomplished, and no way for the user to control
it. In particular, there is no protocol by which a user can write a
print-function for a structure, or a method for PRINT-OBJECT, that will
interact smoothly with the built-in pretty-printer in a portable manner.
Proposal (PRETTY-PRINT-INTERFACE:XP):
Adopt the interfaces and protocols of the XP pretty-printer by Dick Waters,
described in full in the attached 12-page document. Here is a very brief
summary of the proposal.
New variables: *PRINT-DISPATCH*
*PRINT-RIGHT-MARGIN*
*DEFAULT-RIGHT-MARGIN*
*PRINT-MISER-WIDTH*
*PRINT-LINES*
*LAST-ABBREVIATED-PRINTING*
New function: COPY-PRINT-DISPATCH
New macro: DEFINE-PRINT-DISPATCH
New FORMAT directives: ~W ~_ ~I ~:T ~/name/ ~<...~:>
New # reader macro: #"..."
The function WRITE is extended to accept additional keyword arguments
:DISPATCH, :RIGHT-MARGIN, :LINES, and :MISER-WIDTH corresponding to the
first four of the new variables.
Examples: See attached document.
Rationale:
There ought to be a good user interface to the pretty printer.
This is the only proposal for which there is a portable implementation
that has seen extensive use and is being made freely available.
Current practice:
XP son of PP son of GPRINT son of PRINT* is the latest in a line of pretty
printers that goes back 13 years. All of these printers use essentially
the same basic algorithm and conceptual interface. Further, except for
PRINT*, which was implemented solely to satisfy the author's personal
needs, each of these printers has had extensive use. XP has been in
experimental use as the pretty printer in CMU Common Lisp for 6 months. PP
has been the pretty printer in DEC Common Lisp for the past 3 years. Prior
to three years ago, GPRINT was used for 2 years as the pretty printer in
DEC Common Lisp. In addition, GPRINT has been the pretty printer in
various generations of Symbolics Lisp for upwards of 5 years.
(See Waters R.C., "User Format Control in a Lisp Prettyprinter", ACM TOPLAS,
5(4):513--531, October 1983.)
Cost to Implementors:
A fair amount of effort (perhaps a few man-weeks at most).
Source code for XP is available to all comers from Dick Waters, and
the system is documented in great detail:
Waters, Richard C., "XP: A Common Lisp Pretty Printing System",
Artificial Intelligence Laboratory Technical Memo 1102,
Massachusetts Institute of Technology, Cambridge MA, March 1989.
Cost to Users: None (I think). This is an upward-compatible extension.
Cost of non-adoption: Continued inability for user print-functions
to interact with the pretty-printer in a useful and portable manner.
Performance impact: XP is claimed to be quite fast.
Benefits: User control of pretty-printing in a portable manner.
Esthetics:
Using ~<...~:> may strike some as uncomfortably close in the syntactic
space of FORMAT directives to the existing ~<...~>. However, it is very
unlikely that both of these directives (pretty-print logical block and
columnar justification, respectively) will be used in the same call to
FORMAT. Previous versions of XP used ~!...~. instead of ~<...~:> but this
made FORMAT strings very difficult to read; it is preferable to have
a directive that looks like matching brackets of some sort.
Discussion:
Zetalisp used ~:T to mean pixelwise tabulation, so the use of ~:T
suggested here may be a problem. If so, another suggestion for naming
this directive would be appropriate.
The ~/.../ directive is already in Zetalisp, and is not an idea new
to this proposal.
Guy Steele and Dick Waters strongly support this proposal. (As an example,
Guy Steele has a portable simulator for Connection Machine Lisp, and would
like very much to have xappings and xectors pretty-print properly.)
!
Pretty Printing
Richard C. Waters
Pretty printing has traditionally been a black box process, displaying
program code using a set of fixed layout rules. Its utility can be greatly
enhanced by opening it up to user control.
By providing direct access to the mechanisms within the pretty printer that
make dynamic decisions about layout, the FORMAT directives ~_, ~I, and
~<...~:> make it possible to specify pretty printing layout rules as a part
of any function that produces output. They also make it very easy for
circularity detection and abbreviation based on length and nesting depth to
be supported by the function. The construct DEFINE-PRINT-DISPATCH makes it
possible to associate a user-defined pretty printing function with any type
of object. Together, these facilities enable users to redefine the way
code is displayed and allow the full power of pretty printing to be applied
to complex combinations of data structures.
Pretty Printing Control Variables
*PRINT-DISPATCH* [variable]
When *PRINT-PRETTY* is not NIL, the print dispatch table in
*PRINT-DISPATCH* controls the way objects are printed. The initial value
of *PRINT-DISPATCH* causes traditional pretty printing of Lisp code.
*PRINT-RIGHT-MARGIN* [variable]
*DEFAULT-RIGHT-MARGIN* [variable]
The goal of dynamic layout decisions (when pretty printing or when directly
specified via ~_, ~I, and ~<...~:>) is to keep the output between a pair of
margins. The left margin is set at the column where the output begins. If
this cannot be determined, the left margin is set to zero.
When *PRINT-RIGHT-MARGIN* is not NIL, it specifies the right margin to use
when making layout decisions. When *PRINT-RIGHT-MARGIN* is NIL (the
initial value), the right margin is set at the maximum line length that can
be displayed by the output stream without wraparound or truncation. If
this cannot be determined, the right margin is set to
*DEFAULT-RIGHT-MARGIN*. The initial value of *DEFAULT-RIGHT-MARGIN* is
implementation-dependent.
*PRINT-MISER-WIDTH* [variable]
If *PRINT-MISER-WIDTH* is not NIL, the pretty printer switches to a compact
style of output (called miser style) whenever the width available for
printing a substructure is less than or equal to *PRINT-MISER-WIDTH*. The
initial value of *PRINT-MISER-WIDTH* is implementation-dependent.
!
*PRINT-LINES* [variable]
When given a value other than its initial value of NIL, *PRINT-LINES*
limits the number of output lines produced when something is printed. If
an attempt is made to go beyond *PRINT-LINES* lines, " ---" is printed at
the end of the last line and printing stops.
(let ((*print-right-margin* 20) (*print-lines* 3))
(pprint '(setq a 1 b 2 c 3 d 4)))
(SETQ A 1
B 2
C 3 ---
*LAST-ABBREVIATED-PRINTING* [variable]
This variable records the last printing event where abbreviation occurred.
Funcalling its value (e.g., after turning off abbreviation) causes the
printing to happen a second time.
The function WRITE accepts keyword arguments :DISPATCH, :RIGHT-MARGIN,
:LINES, and :MISER-WIDTH corresponding to *PRINT-DISPATCH*,
*PRINT-RIGHT-MARGIN*, *PRINT-LINES*, and *PRINT-MISER-WIDTH*.
Compiling Format Control Strings
The control strings used by FORMAT are essentially programs that perform
printing. The readmacro character #"..." provides the efficiency of using
a compiled function for printing without losing the conciseness of FORMAT
control strings. In the notation #"...", the string following # is
identical to a FORMAT control string. However, the readmacro translates it
into an equivalent sharp-quoted function. The first expression below is
equivalent to the second.
#"~%~@{~S~↑, ~}"
#'(lambda (stream &rest args)
(terpri stream)
(loop (prin1 (pop args) stream)
(if (null args) (return nil))
(write-string ", " stream)))
In support of the above, FORMAT accepts functions as its second argument as
well as strings. When a function is provided, it is called with the
appropriate output stream as its first argument and the data arguments to
FORMAT as its remaining arguments. The function should perform whatever
output is necessary. The values returned by the function are ignored. The
directive ~? also accepts functions as well as control strings.
!
Dynamic Control of the Arrangement of Output
The following FORMAT directives support precise control of what should be
done when a piece of output is too large to fit in the space available.
Three concepts underlie the way these directives work---`logical blocks',
`conditional newlines', and `sections'.
The first line of Figure 1 shows a schematic piece of output. The
characters in the output are represented by "-". The positions of
conditional newlines are indicated by digits. The beginnings and ends of
logical blocks are indicated by "<" and ">" respectively.
The output as a whole is a logical block and the outermost section. This
section is indicated by the 0's on the second line of Figure 1. Logical
blocks nested within the output are specified by ~<...~:> directives.
Conditional newline positions are specified by ~_ directives. Each
conditional newline defines two sections (one before it and one after it)
and is associated with a third (the section immediately containing it).
The section after a conditional newline consists of: all the output up to,
but not including, (a) the next conditional newline immediately contained
in the same logical block; or if (a) is not applicable, (b) the next
newline that is at a lesser level of nesting in logical blocks; or if (b)
is not applicable, (c) the end of the output.
The section before a conditional newline consists of: all the output back
to, but not including, (a) the previous conditional newline that is
immediately contained in the same logical block; or if (a) is not
applicable, (b) the beginning of the immediately containing logical block.
The last four lines in Figure 1 indicate the sections before and after the
four conditional newlines.
The section immediately containing a conditional newline is the shortest
section that contains the conditional newline in question. In Figure 1,
the first conditional newline is immediately contained in the section
marked with 0's, the second and third conditional newlines are immediately
contained in the section before the fourth conditional newline, and the
fourth conditional newline is immediately contained in the section after
the first conditional newline.
<-1---<--<--2---3->--4-->->
000000000000000000000000000
11 111111111111111111111111
22 222
333 3333
44444444444444 44444
Figure 1: Example of logical blocks, conditional newlines, and sections.
Whenever possible, the pretty printer displays the entire contents of a
section on a single line. However, if the section is too long to fit in
the space available, line breaks are inserted at conditional newline
positions within the section.
!
~W [format directive]
WRITE -- An arg, any Lisp object, is printed obeying every printer control
variable (as by WRITE). In addition, ~W interacts correctly with depth
abbreviation, by not resetting the depth counter to zero. ~W does not
accept parameters. If given the colon modifier, ~W binds *PRINT-PRETTY* to
T. If given the atsign modifier, ~W binds *PRINT-LEVEL* and *PRINT-LENGTH*
to NIL.
~W provides automatic support for circularity detection. If *PRINT-CIRCLE*
is T and ~W is applied to an argument that has already been encountered
during the printing process, an appropriate #n# marker is inserted in the
output instead of printing the argument.
Circularity detection is supported by effectively doing the printing twice.
On the first pass, circularities are detected and the actual outputting of
characters is suppressed. On the second pass, the appropriate #n= and #n#
markers are inserted and characters are output.
~_ [format directive]
CONDITIONAL NEWLINE -- Without any modifiers, ~_ specifies a
`linear-style' conditional newline. A line break is inserted if and only
if the immediately containing section cannot be printed on one line. The
effect of this is that line breaks are either inserted at every
linear-style conditional newline in a logical block or at none of them.
~@_ specifies a `miser-style' conditional newline. A line break is
inserted if and only if the immediately containing section cannot be
printed on one line and miser style is in effect in the immediately
containing logical block. The effect of this is that miser-style
conditional newlines act like linear-style conditional newlines, but only
when miser style is in effect. Miser style is in effect for a logical
block if and only if the the starting column of the logical block is less
than or equal to *PRINT-MISER-WIDTH* columns from the right margin.
~:_ specifies a `fill-style' conditional newline. A line break is
inserted if and only if either (a) the following section cannot be printed
on the end of the current line, (b) the preceding section was not printed
on a single line, or (c) the immediately containing section cannot be
printed on one line and miser style is in effect in the immediately
containing logical block. If a logical block is broken up into a number
of subsections by fill-style conditional newlines, the basic effect is
that the logical block is printed with as many subsections as possible on
each line. However, if miser style is in effect, fill-style conditional
newlines act like linear-style conditional newlines.
~:@_ specifies a `mandatory-style' conditional newline. A line break is
always inserted. This implies that none of the containing sections can be
printed on a single line and will therefore trigger the insertion of line
breaks at linear-style conditional newlines in these sections.
When a line break is inserted by any type of conditional newline, any
blanks that immediately precede the conditional newline are omitted from
the output and indentation is introduced at the beginning of the next line.
By default, the indentation causes the following line to begin in the same
column as the first character in the immediately containing logical block.
The indentation can be changed via ~I.
There are a variety of ways unconditional newlines can be introduced into
the output (e.g., via ~% or by printing a string containing a newline
character). As with mandatory conditional newlines, this prevents any of
the containing sections from being printed on one line. In general, when
an unconditional newline is encountered, it is printed out without
suppression of the preceding blanks and without any indentation following
it. However, if a per-line prefix has been specified (see ~<...~:>), this
prefix will always be printed no matter how a newline originates.
!
~<...~:> [format directive]
LOGICAL BLOCK -- If ~:> is used to terminate a ~<...~>, the directive
delimits a logical block. In addition, ~<...~:> descends into the
corresponding FORMAT argument (a list) in the same way as the directive
~1{...~:}. ~↑ can be used to exit from ~<...~:> just as it can be used to
exit from ~{...~}.
The portion of a FORMAT control string enclosed in ~<...~:> can be divided
into segments ~<prefix~;body~;suffix~:> by ~; directives. It is an error
for the enclosed portion to be divided into more than three segments. If
the enclosed portion is divided into only two segments, the suffix defaults
to the null string. If the enclosed portion consists of only a single
segment, both the prefix and the suffix default to the null string. If the
colon modifier is used with ~<...~:>, the prefix and suffix default to "("
and ")" (respectively) instead of to the null string.
The prefix and suffix must both be constant strings. They cannot contain
FORMAT directives. The body can be any arbitrary FORMAT control string.
The prefix is printed out just before the logical block is started and the
suffix is printed out just after the logical block ends. This is done even
when the argument corresponding to ~<...~:> is an empty list.
If ~<...~:> is applied to an argument that is not a list, the directive is
ignored (suppressing the output of the prefix and suffix) and the offending
argument is printed using ~W. This makes it easier to write FORMAT strings
that are robust in the face of malformed arguments.
During the processing of the FORMAT string nested in ~<...~:>, arguments
are taken one by one from the list passed to ~<...~:>. If an attempt is
made to access an argument at a time when the remaining portion of this
argument list is not a cons, then ". " is inserted in the output, ~W is
used to print out the remaining argument list, and the processing of the
logical block is terminated, except for printing the suffix (if any). This
makes it easier to write FORMAT strings that are robust in the face of
malformed argument lists. (Note that ~↑ exits only when the remaining
argument list is NIL.)
~<...~:> provides automatic support for depth abbreviation. If
*PRINT-LEVEL* is not NIL and ~<...~:> is encountered at a dynamic nesting
depth in logical blocks greater than *PRINT-LEVEL*, "#" is inserted in the
output and the ~<...~:> and its associated argument are ignored.
~<...~:> provides automatic support for length abbreviation. If
*PRINT-LENGTH* is not NIL, a count is kept of the number of arguments used
within the ~<...~:>. If this count ever reaches *PRINT-LENGTH*, " ..." is
inserted in the output and the processing of the logical block is
terminated, except for printing the suffix (if any).
~<...~:> also provides automatic support for circularity detection. If
*PRINT-CIRCLE* is T and ~<...~:> (without the atsign modifier) is applied
to a list argument that has already been encountered during the printing
process, an appropriate #n# marker is inserted in the output and the
~<...~:> and its associated argument are ignored.
!
In addition, if an attempt is made to access an argument from the list
passed to ~<...~:>, at a time when the remaining portion of this list has
already been encountered during the printing process, ". #n#" is inserted
in the output and the processing of the logical block is terminated, except
for printing the suffix (if any). This catches instances of CDR
circularity in lists.
For circularity detection to work correctly when printing an object, every
part of the object that is a cons must be printed using ~<...~:> and every
non-cons must be printed using ~W. If some part is printed some other way
(e.g., using ~S), circularities involving this part will be missed.
If the atsign modifier is used with ~<...~:>, the entire remaining argument
list is passed to the directive as its argument. Unlike ~1@{...~} all of
the remaining arguments are always consumed by ~@<...~:>, even if they are
not all used by the FORMAT string nested in the directive.
As an example of the interaction of conditional newlines and logical
blocks, consider the following. The FORMAT string specifies how to pretty
print a LET. The outermost ~:<...~:> decomposes the input and specifies
that parentheses should be printed in the output. The
~:<~@{~:<~@{~W~↑~ _~}~:>~↑ ~:_~}~:> decomposes the list of binding pairs.
Each pair in the list is itself decomposed and printed using
~:<~@{~W~↑ ~_~}~:>. (An iteration is used in this FORMAT string instead of
merely decomposing the pair into two elements so that a malformed pair
containing more than two elements will print readably.) A space and a
fill-style conditional newline are placed after each pair except the last.
The ~@{~↑~_ ~W~} prints out the forms in the body of the LET separated by
spaces and linear-style conditional newlines.
(format T #"~:<~W~↑ ~:<~@{~:<~@{~W~↑ ~_~}~:>~↑ ~:_~}~:>~
~@{~↑~_ ~W~}~:>"
'#1=(let (x (*print-length* (f (g 3)))
(z . 2) (k (car y)))
(setq x (sqrt z)) #1#))
Suppose that *PRINT-PRETTY* is T, *PRINT-LEVEL* is 4, and *PRINT-CIRCLE* is
T. If the line length is greater than or equal to 77, the output produced
by the FORMAT above appears on one line. However, if the line length is
76, line breaks are inserted at the linear-style conditional newlines
separating the forms in the body and the output below is produced. Note
that, the degenerate binding pair X is printed readably even though it
fails to be a list; a depth abbreviation marker is printed in place of
(G 3); the binding pair (Z . 2) is printed readably even though it fails
to be a proper list; and appropriate circularity markers are printed.
#1=(LET (X (*PRINT-LENGTH* (F #)) (Z . 2) (K (CAR Y)))
(SETQ X (SQRT Z))
#1#)
If the line length is reduced to 35, a line break is inserted at one of the
fill-style conditional newlines separating the binding pairs.
#1=(LET (X (*PRINT-PRETTY* (F #))
(Z . 2) (K (CAR Y)))
(SETQ X (SQRT Z))
#1#)
!
Suppose that the line length is further reduced to 22 and *PRINT-LENGTH* is
set to 3. In this situation, line breaks are inserted after both the first
and second binding pairs. In addition, the second binding pair is itself
broken across two lines. Clause (b) of the description of fill-style
conditional newlines prevents the binding pair (Z . 2) from being printed
at the end of the third line. Note that the length abbreviation hides the
circularity from view and therefore the printing of circularity markers
disappears as well.
(LET (X
(*PRINT-LENGTH*
(F #))
(Z . 2) ...)
(SETQ X (SQRT Z))
...)
If ~@; is used to terminate the prefix in ~<...~:>, the prefix is a
`per-line' prefix. A per-line prefix is printed at the beginning of every
line in the logical block, rather than just before the start of the block
as a whole. Each instance of the prefix is lined up below the occurrence
of the prefix on the first line. With a line length of 25, the form below
produces the output shown.
(format T #"~<;;; ~@;Roads ~<= ~@;~W, ~:_~W~:> ~:_ Town ~W~:>"
'((elm cottonwood) boston))
;;; Roads = ELM,
;;; = COTTONWOOD
;;; Town BOSTON
If ~<...~:> is terminated with ~:@>, then a fill-style conditional newline
is automatically inserted after each group of blanks immediately contained
in the body (except for blanks after a ~<newline> directive). This makes
it easy to achieve the equivalent of paragraph filling. With a line length
of 12, the form below produces the output shown.
(format T #"~<~:(~W~) street goes to ~:(~W~).~:@>"
'(main boston))
Main street
goes to
Boston.
To a considerable extent, the basic form of the directive ~<...~> is
incompatible with the dynamic control of the arrangement of output by ~W,
~_, ~<...~:>, ~I, and ~:T. As a result, it is an error for any of these
directives to be nested within ~<...~>. Beyond this, it is also an error
for the ~<...~:;...~> form of ~<...~> to be used at all in conjunction with
any of these directives.
!
~I [format directive]
INDENT -- ~nI specifies that the indentation within the immediately
containing logical block should be set to the column position of the first
character in the block plus n. If omitted, n defaults to zero. The
parameter can be negative; however, the total indentation cannot be moved
left of the beginning of the line or left of the end of the rightmost
per-line prefix. ~n:I is exactly the same as ~nI except that it operates
relative to the position in the output of the directive itself, rather than
relative to the first character in the block. Changes in indentation
caused by a ~I directive do not take effect until after the next line
break. Consider the following example:
(format T #"~:<~W ~@_~:I~W ~:_~W ~1I~_~W~:>"
'(defun prod (x y) (* x y)))
If the line width available is 15, both the ~:_ and the ~_ are replaced by
line breaks. The ~:I directive before the ~W that prints the function name
causes the argument list to be lined up under the function name. The ~1I
directive before the ~_ specifies that the statement in the body of the
DEFUN should be printed at a relative indentation of 1 in the logical
block.
(DEFUN PROD
(X Y)
(* X Y))
In miser style, all ~I directives are ignored, forcing the lines
corresponding to the logical block to line up under the first character in
the block. If *PRINT-MISER-WIDTH* were greater than or equal to 14 (the
block begins in the second column, after the prefix "(" IS printed), the
example output above would have been as follows.
(DEFUN
PROD
(X Y)
(* X Y))
~:T [format directive]
TABULATE -- If the colon modifier is used with the ~T directive, the
tabbing computation is done relative to the column where the section
immediately containing the directive begins, rather than with respect to
column zero. Consider the following example. Each street name is followed
by a ~8:T, which ensures that the total width taken up will be a multiple
of 8. With a line width of 25, the output shown is produced.
(format T #"~<Roads ~:I~@_~@{~W~↑~8:T~:_~}~:>"
'(elm main maple center))
Roads ELM MAIN
MAPLE CENTER
!
~/name/ [format directive]
CALL FUNCTION -- User defined functions can be called from within a FORMAT
string by using the directive ~/name/. The colon modifier, the atsign
modifier, and arbitrarily many parameters can be specified with the ~/name/
directive. The name can contain a package prefix, but it cannot contain
"/". If the readmacro #"..." is used, the default package associated with
name will be the value of *PACKAGE* at the moment the #"..." is read. If
an ordinary FORMAT control string is used, the default package will be the
value of *PACKAGE* at the moment the string is processed by FORMAT.
When a ~/name/ directive is encountered, the indicated function is called
with four or more arguments. The first four arguments are: the output
stream, the FORMAT argument corresponding to the directive, the value T if
the colon modifier was used (NIL otherwise), and the value T if the atsign
modifier was used (NIL otherwise). The remaining arguments consist of any
parameters specified with the directive. The function should print the
argument appropriately. Any values returned by the function are ignored.
~/LINEAR-STYLE/ [format directive]
An argument, a list, is printed so that either all of the elements are on
one line or each element is on a separate line. Parentheses are printed
around the list if the colon modifier is specified. As an example of a
function intended to be called from within a FORMAT string, the definition
of LINEAR-STYLE is shown below.
(defun linear-style (stream list &optional (colon? T) atsign?)
(declare (ignore atsign?))
(if colon?
(format stream #"~:<~@{~W~↑ ~_~}~:>" list)
(format stream #"~<~@{~W~↑ ~_~}~:>" list)))
~/FILL-STYLE/ [format directive]
An argument, a list, is printed with as many elements as possible on each
line. Parentheses are printed around the list if the colon modifier is
specified.
~/TABULAR-STYLE/ [format directive]
An argument, a list, is printed in a tabular form with as many elements as
possible on each line. In addition to the colon modifier, which causes
parentheses to be printed, ~/TABULAR-STYLE/ takes a parameter
(default 16) that specifies the width of columns in the table.
!
Print Dispatch Tables
Pretty printing is directed by print dispatch tables.
COPY-PRINT-DISPATCH &optional (table *PRINT-DISPATCH*) [function]
A copy is made of table, which defaults to the current print dispatch
table. If table is NIL, a copy is made of the initial print dispatch
table.
DEFINE-PRINT-DISPATCH type-specifier options &body function [macro]
This puts an entry into a print dispatch table. The type-specifier
(which is implicitly quoted) is the key of the entry. The function
specifies how to pretty print the indicated type of object. When
appropriate, the function is called with two arguments: an output
stream and the object to print. Any values returned by the function are
ignored. The options are a list of pairs containing a keyword and a
value. Three different keywords are supported:
(:TABLE table)
Specifies the table (default *PRINT-DISPATCH*) to put the dispatch entry
into.
(:PRIORITY number)
Specifies a priority (default 0) used to resolve conflicts when an object
matches more than one entry.
(:NAME name)
Specifies a name to be given to function. This makes it possible to
reuse the function---e.g., in another call on DEFINE-PRINT-DISPATCH.
Before doing anything else, DEFINE-PRINT-DISPATCH removes any existing
entry with a type specifier EQUAL to the given type specifier. A new
entry containing the given priority and function is then created.
The function in a DEFINE-PRINT-DISPATCH call can be specified in five
different ways. First, the function can be NIL. In this case, no new
entry is made after the old entry (if any) is removed. Second, the
function can be omitted altogether. In this case, the standard pretty
printing function (if any) corresponding to the type specifier is entered
into the table. Third, the function can be an argument list followed by a
body consisting of one or more statements. (The use of &REST X in the
argument list below makes it possible to use ~/RATIO-PRINT/ in a FORMAT
string.)
(define-print-dispatch ratio ((:name ratio-print))
(s obj &rest x)
(declare (ignore x))
(format s #"#.(/ ~W ~W)" (numerator obj) (denominator obj)))
(pprint '(2/3 -4/5)) prints: (#.(/ 2 3) #.(/ -4 5))
!
Fourth, the function can be an instance of #"...".
(define-print-dispatch (and ratio (satisfies plusp))
((:priority 1))
#"(+ ~/ratio-print/)")
(pprint '(2/3 -4/5)) prints: ((+ #.(/ 2 3)) #.(/ -4 5))
Fifth, the function can be a sharp-quoted function name. The definition
below shows the default method used for printing lists that represent data,
rather than programs. (As shown in the definition of LINEAR-STYLE above,
LINEAR-STYLE, FILL-STYLE, and TABULAR-STYLE are all defined with their
COLON? and ATSIGN? arguments optional so that they can be used as
DEFINE-PRINT-DISPATCH functions.)
(define-print-dispatch cons ((:priority -10)) #'fill-style)
The entry to use for printing an object is selected by looking at the
entries in *PRINT-DISPATCH* in the order of their priorities. The first
entry whose type specifier matches the object is chosen. If an object
matches two entries with the same priority, an arbitrary choice is made.
If no entry matches the object, the object is printed as if *PRINT-PRETTY*
were NIL.
(CONS car-type cdr-type) [type specifier]
When used simply as the symbol CONS, this type specifier matches any
cons cell. When used in the form above, it matches a cons cell only if the
car of the cell matches the type specifier car-type and the cdr of
the cell matches the type specifier cdr-type. The cdr-type can
be omitted in which case it defaults to T.
The examples below show three of the predefined pretty printing functions
for Lisp code. By default, function calls are printed in the standard
way---i.e, either all on one line or with the arguments one to a line
indented after the function name.
(define-print-dispatch (cons (and symbol (satisfies fboundp)))
((:priority -5))
#"~:<~W~↑ ~:I~@_~@{~W~↑ ~_~}~:>")
Lists beginning with COND are printed the same way as function calls,
except that the clauses are always printed in linear style, rather than in
the format suggested by their cars.
(define-print-dispatch (cons (member cond)) ()
#"~:<~W~↑ ~:I~@_~@{~:/linear-style/~↑ ~_~}~:>")
Lists beginning with QUOTE are printed using the standard "'" syntax. Note
the care taken to ensure that data lists that happen to begin with QUOTE
will be printed legibly.
(define-print-dispatch (cons (member quote)) () (s list)
(if (and (consp (cdr list)) (null (cddr list)))
(format s #"'~W" (cadr list))
(fill-style s list)))
!
In addition to the last four entries shown above, the initial print
dispatch table contains approximately fifty additional entries with type
specifiers of the form (CONS (MEMBER symbol)) and priority zero for various
Lisp special forms and macros. There are no other predefined pretty
printing functions for data structures other than lists. However, as shown
below, such entries can easily be defined.
(defstruct family mom kids)
(define-print-dispatch family () (s f)
(format s #"~@<#<~;~W and ~2I~_~/fill-style/~;>~:>"
(family-mom f) (family-kids f)))
The pretty printing function for the structure FAMILY specifies how to
adjust the layout of the output so that it can fit aesthetically into a
variety of line widths. In addition, it obeys the printer control
variables *PRINT-LEVEL*, *PRINT-LENGTH*, *PRINT-LINES*, *PRINT-CIRCLE*, and
*PRINT-ESCAPE*, and can tolerate several different kinds of malformity in
the data structure. The output below shows what happens with line width
25, *PRINT-PRETTY T, *PRINT-ESCAPE* NIL, and a malformed KIDS list.
(write (list 'principle-family
(make-family :mom "Lucy"
:kids '("Mark" "Bob" . "Dan"))))
(PRINCIPLE-FAMILY
#<Lucy and
Mark Bob . Dan>)
Note that a pretty printing function for a structure is different from the
structure's print function. While print functions are permanently
associated with a structure, pretty printing functions are stored in print
dispatch tables and can be rapidly changed to reflect different printing
needs. If there is no pretty printing function for a structure in the
current print dispatch table, the print function (if any) is used instead.
[End of attached document]
∂27-Feb-89 0938 CL-Cleanup-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 27 Feb 89 09:37:15 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07069; 27 Feb 89 17:20 GMT
Date: Mon, 27 Feb 89 17:23:28 GMT
Message-Id: <3256.8902271723@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Potential issue: MACRO-SPECIAL-FORMS
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>
In-Reply-To: Kent M Pitman's message of Thu, 23 Feb 89 17:43 EST
Cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Kent --
Either you misunderstood what I said, or I failed to state it with
sufficient clarity. I was not trying to say that *all* implementation-
dependent functions in macro expansions (of constructs documented as
macros in CLtL) are bad, but rather that *certain kinds of functions*
are. So the CltL claim that "there is no problem" with functions is
wrong, and I was hoping that we might be able to rule out the bad
functions while keeping the good ones.
It was not my goal to eliminate calls to all functions that do "magic
things that no user could ever possibly hope to write", because, as
you point out, many "usually-seen-as-ordinary" functions have that
property. Rather, I wanted to deal with the possibility that an
implementation might satisfy the letter of the law but nonetheless, by
using functions and quoted arguments instead of out-and-out special
forms, still make it impossible for code-walkers and the like to
reliably find all the forms in an expression.
> Date: Thu, 23 Feb 89 22:00:42 GMT
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> For example, a special form (sf . args) might expand to
> (do-an-sf '(sf . args)), where do-an-sf is an implementation
> -dependent function.
> A program-analyzing program learns nothing of value from such
> an expansion.
> This part is not true and weakens your earlier point (which I think is
> well-taken).
Well, consider my example with 'sf' instantiated to UNWIND-PROTECT
(which isn't defined as a macro and so isn't really a proper instance
of the problem), and 'args' to ((FOO) (BAR)). You write:
> For example, if UNWIND-PROTECT were not a standard special form but
> was added by some implementation with a macroexpander that turned
>
> (UNWIND-PROTECT (FOO) (BAR))
> into
> (SI::UNWIND-PROTECT-FUNCTION #'(LAMBDA () (FOO))
> #'(LAMBDA () (BAR)))
> this would be fine.
I agree that this is fine. But suppose it expanded (as in my example)
to:
(DO-AN-UNWIND-PROTECT
'(UNWIND-PROTECT (FOO) (BAR)))
That is not fine. I don't think anything in CLtL rules it out,
and I have seen things like it in at least one implementation.
> While you're right when you say I don't "learn" anything from
> examining the latter form, you're wrong when you fail to observe that
> I can `walk' the latter form reliably, while I cannot walk the former.
I meant "learn" to be interpreted rather loosely. The result is not
a useful one, because everything is hidden inside the QUOTE and so
would be ignored by a code-walker.
> For example, the implementation of Flavors used by Cloe uses a
> code-walker [...] What is important to that code walker (and a whole
> class of code walkers like it) is that it know what parts of something
> are `evaluated normally,' what parts are `evaluated specially,' and
> what parts are `not evaluated.'
I agree about what is important. I was trying to say something
similar in the "not quite a proposal":
The basic goal is that the intent of the macro definition should be
evident in the expansion. Subexpressions of the macro call that are
identified syntactically as forms should appear as forms in the
expansion, variables should appear as variables, and so on. But we
can't say they must appear only as forms, variables, and so on; so
it's not clear that the goal is an attainable one. There are
presumably other problems as well.
-- Jeff
∂27-Feb-89 1337 CL-Cleanup-mailer [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 27 Feb 89 13:36:58 PST
Received: from fafnir.think.com by Think.COM; Mon, 27 Feb 89 13:12:27 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 27 Feb 89 13:10:15 EST
Received: by verdi.think.com; Mon, 27 Feb 89 13:10:47 EST
Date: Mon, 27 Feb 89 13:10:47 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902271810.AA18268@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
To: common-lisp@sail.stanford.edu
Subject: pluralization: two proposals
Date: Mon, 27 Feb 89 04:37:06 EST
From: Dave.Touretzky@B.GP.CS.CMU.EDU
The ~P format directive and its : and @ variants provide only the suffixes
"s" and "ies". What about nouns whose singular forms end in "s" or
"z"? They use "es" to form their plural, e.g.
bus --> buses
glass --> glasses
buzz --> buzzes
First, I propose that ~P and ~:P be modified to produce the "es" plural
form instead of "s" when given a numeric argument of -1.
Second, a more ambitious proposal: how about introducing a new conditional
directive to handle arbitrary singular/plural distinctions:
~:@[ singular ~; plural ~]
If the argument is EQL to 1, the first alternative is taken; otherwise the
second alternative is taken. This lets you do neat things like:
(format nil "There ~:@[is~;are~]~:* ~D~:* ~:@[wolf~;wolves~] here." 3)
==> "There are 3 wolves here."
(format nil "There ~:@[is~;are~]~:* ~D~:* ~:@[wolf~;wolves~] here." 1)
==> "There is 1 wolf here."
(format nil "Your tab comes to ~D~:* ~:@[wolfs'~;wolves'~] head~:P." -5)
==> "Your tab comes to -5 wolves' heads."
(format nil "Your tab comes to ~D~:* ~:@[wolf's~;wolves'~] head~:P." 1)
==> "Your tab comes to 1 wolf's head."
Notes:
1) The example with -5 shows why special plural forms can't simply be
handled with an ordinary conditional by writing
~[plural~;singular~:;plural~]
2) The pluralization conditional is also useful for handling things like
possessive forms (wolf's vs. wolves') and the verb "be" (is vs. are).
-- Dave
∂27-Feb-89 1433 CL-Cleanup-mailer Re: PRETTY-PRINT-INTERFACE
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 27 Feb 89 14:32:54 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA04127; Mon, 27 Feb 89 17:31:20 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA09796; Mon, 27 Feb 89 17:29:26 EST
Message-Id: <8902272229.AA09796@mist.>
To: Guy Steele <gls@Think.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: PRETTY-PRINT-INTERFACE
In-Reply-To: Your message of Fri, 24 Feb 89 17:40:25 -0500.
<8902242240.AA10382@verdi.think.com>
Date: Mon, 27 Feb 89 17:29:24 EST
From: Dan L. Pierson <pierson@mist.encore.com>
You can add me to the list of strong supporters of this proposal.
While the proposal is long and complex, it is supported by a long
history of usage in several different Lisp environments. Unlike some
earlier members of this family, this version fits cleanly enough into
the rest of Common Lisp to warrant standardization.
A couple of specific comments:
Under aesthetics you might mention that some people will undoubtedly
find piling more hair on FORMAT ugly (of course these same people may
well find FORMAT in general ugly :-)).
The utility of *PRINT-LINES* becomes more obvious if it is pointed out
that Dick's pretty printers are implemented to print each line as it
is computed. This means that a small value for *PRINT-LINES* saves
significant time as well as output medium space. In fact, many people
find that a very pleasant REP loop is created by setting *PRINT-LINES*
to a value from 1-4, *PRINT-PRETTY* to T, and defining a short-name
function (say (PP*)) that funcalls *LAST-ABBREVIATED-PRINTING* with
abbreviation bound off. This is almost as fast and compact as, and
MUCH more readable than, a non-pretty-printing REP loop.
The advantages of compiled format strings (format functions) should be
brought out as benefits in their own right. The current proposal just
mentions them as a minor feature of XP.
At first this struck me a very cute end run around the failure of
STREAM-INFO, then I realized that one of the problems with STREAM-INFO
may have been that it was a standard at the wrong level. STREAM-INFO
permitted people to use XP, but not to count on it. This proposal
makes it possible to write portable code whose new data structures and
language elements print correctly in whatever Common Lisp environment
they're run in.
∂27-Feb-89 1506 CL-Cleanup-mailer [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Feb 89 15:06:24 PST
Received: from pitney-bowes ([192.9.200.50]) by heavens-gate.lucid.com id AA00328g; Mon, 27 Feb 89 14:59:55 PST
Received: by pitney-bowes id AA02864g; Mon, 27 Feb 89 14:58:31 PST
Date: Mon, 27 Feb 89 14:58:31 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8902272258.AA02864@pitney-bowes>
To: gls@Think.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Guy Steele's message of Mon, 27 Feb 89 13:10:47 EST <8902271810.AA18268@verdi.think.com>
Subject: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
Has anyone thought about what will happen to FORMAT features such as
~P, ~R, ~:R (ordinals), etc. once Common Lisp finally supports
multiple languages? Will English retain a preferred status, or will
there be analogous options for other languages?
Touretzky's proposal would seem to make it easier to accomodate
plurals for other languages, at least those that pluralize in a manner
similar to the English pattern for -1, 0, 1, 2, 3 etc. Are there
obvious languages for which it breaks down?
jlm
∂27-Feb-89 1639 CL-Cleanup-mailer Issue: EXPT-ZERO-ZERO (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Feb 89 16:39:44 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 546824; Mon 27-Feb-89 19:37:43 EST
Date: Mon, 27 Feb 89 19:37 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXPT-ZERO-ZERO (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Cyphers@JASPER.SCRC.Symbolics.COM
References: <19890228000733.1.CYPHERS@SEAR.SCRC.Symbolics.COM>
Message-ID: <890227193717.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: EXPT-ZERO-ZERO
Forum: Cleanup
References: EXPT (pp203-204)
Category: CHANGE
Edit history: 27-Feb-89, Version 1 by Scott Cyphers (Cyphers@Symbolics.COM),
27-Feb-89, Version 2 by Pitman (signals->is an error, misc edits)
Status: For Internal Discussion
Problem Description:
(expt 0 0) is mathematically undefined, but CLtL defines it as
being 1 in most cases.
Proposal (EXPT-ZERO-ZERO:MAKE-UNDEFINED):
Make (expt 0 0) an error for zeros of all types.
That is, it has ``undefined effect.''
Test Case:
(EXPT 0 0) => 1 ;according to CLtL
(EXPT 0 0) is undefined ;proposed
Rationale:
0
For some examples of the behavior of 0 , consider:
X
1) Lim 0 = 0
X->0
ln k
2) Y(X) = --------
c + ln X
Lim Y(X) = 0
X->0
but
Y(X)
Lim X = k
x->0
Current Practice:
Symbolics Genera returns 1 for the test case.
Cost to Implementors:
Technically, there is no cost to implementors because this would become
an ``is an error'' situation, and all implementations that already conform
would continue to conform.
In practice, most implementations would want to detect the error in
high safety situations. In most cases, this is a straightforward change
to one or two functions, and including perhaps some compiler optimizers.
If any implementations have microcoded this operation, the change may
be more complicated.
Cost to Users:
Even though some implementations might not change, users would not be
able to depend on this feature in portable code. Given the mathematical
questionableness of the behavior, however, some of the affected users
may treat a trend toward error detection as a `bug fix.'
Cost of Non-Adoption:
Some mathematical errors will not be detected because CL supplies a
value which is not always appropriate.
Benefits:
In implementations which choose to reliably signal an error in this case,
condition handling can be used to customize the behavior of (expt 0 0)
in a manner appropriate to the application.
Aesthetics:
Cleaner mathematically.
Discussion:
We'd really prefer one of ``must signal'' or ``should signal,'' but
since non-integer 0 powers are already ``is an error'' this is most
consistent.
Cyphers, Pitman, and several other Lisp developers at Symbolics think
this is a good idea.
∂27-Feb-89 1658 CL-Cleanup-mailer Re: Issue: EXPT-ZERO-ZERO (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 27 Feb 89 16:58:12 PST
Received: from Semillon.ms by ArpaGateway.ms ; 27 FEB 89 16:48:42 PST
Date: 27 Feb 89 16:48 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXPT-ZERO-ZERO (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 27 Feb 89 19:37 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU, Cyphers@JASPER.SCRC.Symbolics.COM
Message-ID: <890227-164842-2963@Xerox>
EXPT is a Lisp function that returns only an approximation of the
mathematical function that you want it to represent.
For the case of (EXPT rational integer), however, the behavior is well
defined, and there are no "limit" contradictions to consider. It is nice
that the floating point case concides with the rational/integer case for
arguments other than 0 0, and so there is no reason to make it differ for 0
0.
"Limit" arguments are inappropriate for reasoning about the definition of
floating point functions, since the behavior of the Lisp function and the
corresponding mathematical one differs considerably as soon as you
"approach" , say, least-positive-double-float, for example.
∂28-Feb-89 0240 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Feb 89 02:40:27 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00847g; Tue, 28 Feb 89 02:33:59 PST
Received: by bhopal id AA08748g; Tue, 28 Feb 89 02:36:21 PST
Date: Tue, 28 Feb 89 02:36:21 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8902281036.AA08748@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 15 Feb 89 11:12 PST <890215-111623-12827@Xerox>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
re: I think that the only issue we really have the charter to attack is to
"fix" what we think was a mistake in the wording of the amendment that
was accepted at the last meeting.
There were two sorts of "bugs" in the proposal as brought to, and
voted upon in, Hawai:
(1) a number of little unclarities about the precise relationship
between ADJUSTABLE-ARRAY-P and error signalling in ADJUST-ARRAY
(2) Confusion as to whether or not the type SIMPLE-ARRAY was to
changed from the simple defintion on CLtL p28.
Presumably (1) has been the subject of the volumes of "private" mail,
and much related public mail. However, I still don't see any clear
statement in the latest proposal regarding point (2) -- namely that it
is not trying to change the type SIMPLE-ARRAY. There is in fact a
very confusing statement in the rationale section of the most recent
version:
"Specifying the points left unspecified (requiring all simple arrays to be
non-adjustable and all adjustable arrays to be non-simple) would require
large changes to some implementations and would be of little benefit to
..."
Virtually everyone who reads the last paragraph of CLtL p.28 believes it
to be a _definition_ of SIMPLE-ARRAY (except some folks at Symbolics) --
and that clearly says non-adjustable. In previous mail, I alluded to
reasons why the _utility_ of the type SIMPLE-ARRAY requires it to mean
non-adjustable; that was the clear consensus of all the "stock-hardware"
compiler implementors who where at Hawaii (and at least one other
implementor too). There is simply no point at all in having SIMPLE-ARRAY
in the language if it isn't of critical use to these implementations.
As someone mentioned, there is language in CLtL about how simple-arrays
might be implemented "differently" from implementation to implementation
(i.e., "be more efficient on some implementations", or whatever). Could
that statement be the source that has misled so many people to believe
that the permission to implement the internal structure differently gives
a permission to implement the type differently? Considering the tremendous
amount of time wasted arguing this non point, it would be a great help if
the final version of the issue contained the simple statement:
"This proposal does not alter the definition of SIMPLE-ARRAY in any way."
Here's a synopsis of the damage that can occur unless some such
clarification is made. Consider the following function:
(defun fast-aref (x i)
(declare (optimize (safety 0) (speed 3)))
(check-type x (simple-array t 1))
(setf (aref (the (simple-array t 1) x) i) ;open-compiled
:encountered)
t)
(defparameter foo (make-array 5 :adjustable t))
What happens when FOO is passed to FAST-AREF? If SIMPLE-ARRAY can't be
assured to mean non-adjustable, then either the aforementioned compiler-
writers must give up their long-held technology that allows Lisp to
compete with C; or perhaps they would ignore this issue entirely, and
the portability of Common Lisp would be officially compromised. That is,
if the language permits SIMPLE-ARRAY to mean one thing in one implementation,
and another thing in another implementation (under a false sense of
permitting optional efficiency), then this little example will "break" in
one implementation but will "work" in the other -- in short, the type
SIMPLE-ARRAY will not be portable.
I seriously doubt that the "stock hardware" types will give up their
optimizations. Hence we must ask ourselves whether we would view
non-portability of SIMPLE-ARRAY as a simply a fact that one (or two?)
implementations never did (and never will?) fulfill the definition on
p28; or whether we view it is a **good thing** to be non-portable (as
in the remaining cases of the FIXNUM type). If it comes to the latter,
then I think we will have to admit that the standardization process will
have failed.
-- JonL --
∂28-Feb-89 0949 CL-Cleanup-mailer Issue: EXPT-ZERO-ZERO (Version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 28 Feb 89 09:49:45 PST
Received: from fafnir.think.com by Think.COM; Tue, 28 Feb 89 12:45:56 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 28 Feb 89 12:44:03 EST
Received: by verdi.think.com; Tue, 28 Feb 89 12:44:34 EST
Date: Tue, 28 Feb 89 12:44:34 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902281744.AA02339@verdi.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu, Cyphers@jasper.scrc.symbolics.com
In-Reply-To: Kent M Pitman's message of Mon, 27 Feb 89 19:37 EST <890227193717.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: EXPT-ZERO-ZERO (Version 1)
For what it is worth, W. Kahan of Berkeley recommends that
(expt 0.0 0) => 1.0 but (expt 0.0 0.0) => error.
I believe that the rationale is that in the case of an underflow,
(expt 0.0 0) => 1 saves you when what you were trying to do was
raise some very tiny but non-zero number to an integer power that
turned out to be zero (as in evaluating a polynomial?).
However, in the case of (expt x 0.0) the case is much less clear,
and if underflow is involved in the exponent there is more likely
to be some nuemrical instability.
I realize that this is a bit of a handwave, and I have probably
exceeded the limits of my own competence.
To summarize: yes, there is an essential singularity in the expt
function at (0, 0), but it is nevertheless convenient to define
the result to be 1, at least when the exponent is a rational zero.
--Guy
∂28-Feb-89 1148 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 28 Feb 89 11:47:48 PST
Received: from fafnir.think.com by Think.COM; Tue, 28 Feb 89 14:15:16 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 28 Feb 89 14:13:09 EST
Received: by verdi.think.com; Tue, 28 Feb 89 14:13:37 EST
Date: Tue, 28 Feb 89 14:13:37 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902281913.AA03555@verdi.think.com>
To: jonl@lucid.com
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Tue, 28 Feb 89 02:36:21 PST <8902281036.AA08748@bhopal>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
It is important at this stage to have specific code examples to look at,
and I am glad that Jonl has provided one. Unfortunately, it does not
appear to back his claim. (This is not to say that there cannot be some
other piece of code to back his claim, and I hope that he will produce
another example.)
Date: Tue, 28 Feb 89 02:36:21 PST
From: Jon L White <jonl@lucid.com>
...
Here's a synopsis of the damage that can occur unless some such
clarification is made. Consider the following function:
(defun fast-aref (x i)
(declare (optimize (safety 0) (speed 3)))
(check-type x (simple-array t 1))
(setf (aref (the (simple-array t 1) x) i) ;open-compiled
:encountered)
t)
(defparameter foo (make-array 5 :adjustable t))
What happens when FOO is passed to FAST-AREF?
Let's look at this closely. Consider two implementations (A) and (B). In
(A) ["Symbolics"] an array may be both adjustable and simple; that is,
simpleness might depend on fill-pointerness and displacedness but is
independent of adjustability. In (B) ["stock hardware"] an array can never
be both adjustable and simple.
For each implementation I will consider compile-time actions and then
run-time actions. Assume that both compilers open-code SETF, and for
simplicity assume that displacedness or fill-pointerness does not affect
the open-coding.
(1) The compiler for implementation (A), knowing that simple arrays may
nevertheless be adjustable, will generate code that handles arrays
regardless of adjustability.
The CHECK-TYPE form will determine that the array is simple, and execution
will continue. Because the array is in fact simple, the declaration in the
THE form is correct. The SETF will be executed.
(2) The compiler for implementation (B) is justified in generating open code
for the SETF that does not handle adjustable arrays, because the array has
been declared via THE to be simple, and the compiler knows that in
implementation (B) simple arrays are not adjustable. Moreover, the
compiler is justified in producing such code even at high safety, because
non-simple arrays will not get past the CHECK-TYPE form.
The CHECK-TYPE form will determine that the array is not simple, and an
error will be signalled.
Now, the two implementations behave differently on the example, and that is
a cause for concern.
Let us now examine the two behaviors described above under two different
interpretations of "simple-array" type specifiers. One is the strict
interpretation that adjustable arrays may never be simple. The other is
the more liberal interpretation that I proposed: namely that for
declaration "simple-array" means that you *tried* to make it simple (by
specifying :adjustable nil) or that you have checked that it is simple; and
for discrimination an adjustable array is considered non-simple only if the
implementation in fact relies on that distinction.
Before I proceed further I must reaffirm an important principle on which I
judge correctness and conformance.
It is *not* required that two implementations have the same behavior
when executing an erroneous program.
This has two consequences:
(i) It is permitted for an implementation to extend the language by defining
within that implementation a meaning for particular kinds of erroneous code.
(ii) A programmer may not rely on a valid implementation to identify every
error in a program. In other words, successful execution of a program in
one implementation is not a guarantee that the program is free of errors,
and is not a guarantee that the program will execute successfully in
another implementation. The only guarantee of equivalent execution in two
implmentations is that the program in fact be free of errors.
This principle is relevant to evaluating Jonl's claim:
... if the language permits SIMPLE-ARRAY to mean one thing in one
implementation, and another thing in another implementation (under a
false sense of permitting optional efficiency), then this little example
will "break" in one implementation but will "work" in the other --
in short, the type SIMPLE-ARRAY will not be portable.
because his argument about nonportability is not sound unless the program
in question is correct (and I have seen this argument advanced in previous
discussions in cases where the example under discussion was not correct).
Therefore we must establish that the program is correct before comparing
the implementations. (In preparing this analysis I considered a variant of
the given example in which the CHECK-TYPE form was omitted, and concluded
that this program was erroneous under either interpretation.)
I argue that the program is correct under both interpretations. The
presence of the CHECK-TYPE form is crucial to correctness, for it is
guaranteed to filter out non-simple arrays before the AREF is encountered.
(From the point of view of code generation, it is guaranteed to filter out
arrays that the open code for SETF cannot handle.)
Under the strict interpretation implementation (A) is incorrect by
definition. Under the liberal interpretation implementation (A) is
correct, and accomplishes a useful purpose.
Let us therefore examine the question of which interpretation is to
be preferred.
(a) The strict interpretation would seem to adhere more closely to the
definition of simple arrays given in CLtL, p. 28, and some weight must be
given to adhering to CLtL. However, there is arguably some ambiguity in
the wording, as it refers to an array that "is not to be adjusted"; perhaps
adjustable arrays fall into this category if the program in fact never
makes any attempt to adjust them.
(b) A program might attempt to use adjustability as an explicit
information conduit, rather than simply as advice to the implementation
on speedy array implementations:
(defun hairy-print (a)
(let ((*print-pretty* (typep a 'simple-array)))
(print wazoo)))
(hairy-print (make-array 3 :adjustable nil))
In implementation (A) this would not have the (bizarrely) intended effect.
I conclude that the strict interpretation may be preferred, but not for the
reasons Jonl has advanced! The liberal interpretation does *not* prevent
compilers for stock hardware from producing good code, and therefore the
code example does not support his claim to the contrary.
Moreover, an argument that code might behave differently in two
implementations and therefore impede debugging is rather a red herring,
because (I claim) such differing behaviors occur only when the program is
erroneous (in which case implementations are permitted to differ) or when
the program is using adjustability as an information conduit for reasons
unrelated to getting good array performance.
We may wish to regard the latter point as justification for preferring the
strict interpretation anyway, because implementations are required to
faithfully execute *all* correct programs, not just sensible ones.
Whichever interpretation is agreed upon, let it be for good and careful
reasons. I don't believe that the arguments advanced so far based on a
desire for good open code on stock hardware have yet provided a clear
criterion for preferring one interpretation over the other.
--Guy
∂28-Feb-89 1402 CL-Cleanup-mailer Issue EQUALP-GENERIC
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 89 14:01:05 PST
Date: Tue 28 Feb 89 13:48:20-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue EQUALP-GENERIC
To: cl-cleanup@SAIL.STANFORD.EDU
cc: JonL@LUCID.COM, iim@ECLA.USC.EDU
Message-ID: <12474360416.19.IIM@ECLA.USC.EDU>
In response to JonL's complaint that a proposal to make EQUALP a generic
function did not seem to be forthcoming ...
-----
Forum: Cleanup
Issue: EQUALP-GENERIC
References: EQUALP, p81
Related issues: EQUAL-STRUCTURE
HASH-TABLE-STABILITY
HASH-TABLE-TESTS
Category: CHANGE ADDITION
Edit history: Version 1, 02-28-89, Kim A. Barrett
Problem description:
The recent acceptance of Issue EQUAL-STRUCTURE (as ammended) has generated
some complaints about its specified behavior on objects with metaclass
STRUCTURE-CLASS. Some programs which depend on EQUALP comparing the
components of structures are now broken.
There are some who feel that EQUALP could be made much more useful than it
currently is by making it user extensible, but there are potential
difficulties due to the recent acceptance of Issue HASH-TABLE-TESTS, which
added EQUALP as a valid hash-table test.
Proposal (EQUALP-GENERIC:YES):
Specify that EQUALP is a generic function, and define the new generic function
EQUALP-HASH. Specify that a necessary requirement on all methods for these
functions is that (EQUALP x y) => (= (EQUALP-HASH x t) (EQUALP-HASH y t)).
Add a discussion of the constraints on equivelence predicates and their
corresponding hash functions, similar to that presented in Issue
HASH-TABLE-STABILITY.
EQUALP object1 object2 [Generic Function]
The generic function EQUALP is a predicate which can be called to compare two
objects for equivelence. The precise definition of equivelence is specified
by the methods defined on this function. The result is either true or false,
depending on whether the objects are equivelent.
Method Signatures:
EQUALP (object1 NUMBER) (object2 NUMBER) [Primary Method]
Defines equality as being =.
EQUALP (object1 CHARACTER) (object2 CHARACTER) [Primary Method]
Defines equality as being CHAR-EQUAL.
EQUALP (object1 CONS) (object2 CONS) [Primary Method]
Defines equality as having EQUALP CAR's and EQUALP CDR's.
EQUALP (object1 PATHNAME) (object2 PATHNAME) [Primary Method]
Defines equality as being EQUAL.
EQUALP (object1 VECTOR) (object2 VECTOR) [Primary Method]
Defines equality as having the same length (observing fill-pointers when
present), and every pair of corresponding components are EQUALP.
EQUALP (object1 ARRAY) (object2 ARRAY) [Primary Method]
Defines equality as having the same rank and dimensions, and every pair of
corresponding components are EQUALP.
EQUALP (object1 HASH-TABLE) (object2 HASH-TABLE) [Primary Method]
Defines equality as satisfying the following conditions:
1. Each hash-table uses the same test function.
2. Each hash-table contains entries for the same set of keys, where the test
function is used to determine the equivelence of keys.
3. For each key, the associated values from the two tables are EQUALP.
EQUALP (object1 T) (object2 T) [Primary Method]
The default method defines equality as being EQ.
Remarks:
An error is signaled on an attempt to add a method on any built-in class.
Adding a method on a class after ALLOCATE-INSTANCE has been called on the
class has undefined consequences. Implementations may be extended in this
case.
An implementation may specify additional methods on this function.
EQUALP-HASH object &optional use-pointer depth [Generic Function]
The generic function EQUALP-HASH is a called to compute a hash code for the
Object. Use-Pointer is a flag. If true, the memory location of the object
may be used to generate the hash code. The default is false.
Depth is used to control the depth of recursion, allowing cuttoff. This
prevents infinite recursion in the case of circular references. Callers of
this function should not explicitely specify a value for this argument.
Methods on this function which need to make recursive calls should simply
pass the Depth argument along unchanged.
This function returns two values. The first value is the hash code, which is
a non-negative fixnum. The second value is a flag indicating whether the
memory location of the object (or any component) was used in generating the
hash code. A caller who specifies NIL for the Use-Pointer argument may
reliably depend on the second value being false.
This function is used by the implementation to compute hash codes for EQUALP
hash-tables. By specifying a NIL value for the second argument, it may also
be used to compute a code which is independent of the particular
"incarnation" or "core image", just as for SXHASH.
Method Signatures:
EQUALP-HASH (object NUMBER) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object CHARACTER) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object CONS) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object PATHNAME) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object VECTOR) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object ARRAY) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object HASH-TABLE) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object T) &optional use-pointer depth [Primary Method]
The manner in which the hash code is computed by the standard methods on
this function is implementation dependent.
Remarks:
An error is signaled on an attempt to add a method on any built-in class.
Adding a method on a class after ALLOCATE-INSTANCE has been called on the
class has undefined consequences. Implementations may be extended in this
case.
An implementation may specify additional methods on this function.
Examples:
Test Cases:
Rationale:
It is not possible to determine in a general way what components of
user-defined classes should be examined when computing equality of instances.
By specifying EQUALP to be a generic function which the user can extend, we
allow the user to specify the algorithm for determining equivelence.
The restrictions on adding additional methods are due to the possiblity of
existing data structures having been built up using the previous set of
methods. One way an implementation could be extended would be to provide a
mechanism for marking potentially invalid data structures when new methods are
added.
Current practice:
Probably no current implementation already does this.
Cost to Implementors:
Probably small. An implementation must already support the described
functionality for EQUALP, and must have a function similar to EQUALP-HASH in
order to implement hash-tables with an EQUALP test function. This proposal
merely exposes the hashing function and makes both of these functions
user-specializable.
Cost to Users:
Users who were depending on EQUALP descending into structures will have to
write methods for both functions for the classes they wish to continue to have
this behavior.
Cost of non-adoption:
Performance impact:
Probably small overall, though programs which rely heavily on EQUALP or EQUALP
hash-tables may be affected due to the differing performance of generic
functions compared with normal functions doing type analysis. Presumably the
performance can only be worse than what would be the case if this proposal
were not adopted, since if defining these functions as generic produced better
performance, then the implementation may have already made them generic,
possibly without advertising the fact.
Benefits:
Allows users to specify the proper method for comparing instances of user
defined classes.
Aesthetics:
Discussion:
Other mechanisms for doing the recursion cuttoff in EQUALP-HASH are possible.
The one offered in the proposal is simple and trivial to implement. It is
also kind of ugly, and it is possible that some users might want more than is
offered for this. Maybe some better alternative can be developed.
-------
∂28-Feb-89 1508 CL-Cleanup-mailer Issue EQUALP-GENERIC
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Feb 89 15:08:42 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 547765; Tue 28-Feb-89 18:06:27 EST
Date: Tue, 28 Feb 89 18:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue EQUALP-GENERIC
To: IIM@ECLA.USC.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU, JonL@LUCID.COM
In-Reply-To: <12474360416.19.IIM@ECLA.USC.EDU>
Message-ID: <19890228230626.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
For the record, I oppose making generic any CL function in this
standard.
The fact that DOCUMENTATION and DESCRIBE are generic is perhaps a bad
precedent, but those are mostly used interactively or in `tolerant'
applications anyway.
I side with those who think the issue genericity is an appropriate thing
for a successor standard to study (based on the results of individual
implementations' experimentation).
My principle reason is that I think that making something generic
doesn't necessarily solve the problems it looks like it solves. It seems
to appease those who don't look at it deeply, making them go away and be
quiet because they think they can just go around changing methods
willy-nilly. In fact, though, I think we need to develop some rules
about redefinition, shadowing, and even about documenting protocols
before we can successfully make generic anything which is going to
undergo a heavy pounding. And I don't think we yet have the wisdom to do
any of that.
By the way, I expect the ultimate "wisdom" we do evolve to have rules
against saying things like "the details of how this is done are not
specific" and to require you to have a nice, clear abstract protocol.
I don't think you can write serious code that uses EQUALP without it.
I think people who use EQUALP should do so because they (a) recognize
it to be arbitrary and (b) like that particular arbitrary definition.
I think anyone else should `roll their own.'
If you were able to describe EQUALP in a more abstract way, I would not
oppose you writing an implementation-specific generic function protocol
for your implementation and proposing it (with the results of your years
of testing) for the next standard.
∂28-Feb-89 1758 CL-Cleanup-mailer Issue PRETTY-PRINT-INTERFACE
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 89 17:57:44 PST
Date: Tue 28 Feb 89 17:54:54-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue PRETTY-PRINT-INTERFACE
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12474405302.30.IIM@ECLA.USC.EDU>
The stuff about ~W providing circularity detection, and ~<...~:> providing
depth abbreviation and circularity detection is wrong. This functionality
should always be provided, and not require the use of special format directives
to get it. See the recently passed issue PRINT-CIRCLE-STRUCTURE.
kab
-------
∂01-Mar-89 2009 CL-Cleanup-mailer Re: Issue EQUALP-GENERIC
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Mar 89 20:08:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 MAR 89 19:50:35 PST
Date: Wed, 1 Mar 89 19:50 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Issue EQUALP-GENERIC
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU, JonL@LUCID.COM
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <12474360416.19.IIM@ECLA.USC.EDU>
Message-ID: <19890302035029.0.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Date: Tue, 28 Feb 89 13:48:20 PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Thanks for developing this proposal. Those other ones of us who
mentioned we would think about it have been too swamped.
This message comments on only one small part of your proposal. I may
comment on other parts later.
An error is signaled on an attempt to add a method on any built-in class.
Adding a method on a class after ALLOCATE-INSTANCE has been called on the
class has undefined consequences.
These two points confuse me. I think the first is just covered by one
of the principles outlined in chapter 3. Specifically, the results are
undefined if you define a method on a specified generic function with
specified classes as the specializers. This is really just the obvious
extension of the function redefinition issue. I don't think it is worth
defining a new class of generic function which signals this error.
The second seems well intentioned but unreasonable. For one thing, some
implementations may call allocate-instance before defclass returns. For
another, it seems too painful to suggest that in order to define such a
method you have to boot your lisp first. If this is really the only way
the rest of the proposal can hold together, I think we need to reconsider
the proposal.
-------
∂01-Mar-89 2029 CL-Cleanup-mailer Issue EQUAL-STRUCTURE
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 20:29:13 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02115g; Wed, 1 Mar 89 20:22:38 PST
Received: by bhopal id AA19722g; Wed, 1 Mar 89 20:25:00 PST
Date: Wed, 1 Mar 89 20:25:00 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903020425.AA19722@bhopal>
To: IIM@ECLA.USC.EDU
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Kim A. Barrett's message of Tue 28 Feb 89 13:44:16-PST <12474359674.19.IIM@ECLA.USC.EDU>
Subject: Issue EQUAL-STRUCTURE
re: [incompatibly changing EQUALP on defstruct instances]
I believe you yourself have taken a position on some
issues that the status quo is wrong and needs to be fixed.
Right. But the issue here is whether the fix is:
(1) to drastically rip up the current default behaviour, or
(2) to provide mechanisms that allow users to modify behaviour
[and presumably, he gets the "default" if he doesn't do so].
I've been favoring (2) over (1).
So as-and-when an EQUALP-GENERIC issues comes out, I would favor
retaining the default behaviour for the various broad meta-classes:
(1) BUILT-IN-CLASS: behaviour for objects from this metaclass are
already detailed in CLtL, on a class-by-class (type-by-type?)
basis;
(2) STRUCTURE-CLASS: again, CLtL fairly directly specifies a default
behaviour that needn't be incompatibly changed;
(3) STANDARD-CLASS: I'm not sure if 88-002R spells it out, but I thought
the consensus was that the default behaviour should be to signal
an error [i.e., you shouldn't let it get that far]. Defaulting to
EQL would probably be workable too, but wouldn't be as much help
in finding obscure bugs.
(4) RANDOM-{user-defined}META-CLASS: Might as well take the same tack as
for STANDARD-CLASS, since that is nearly as stringent as possible.
After all, that's what classes (and classes of classes, or "meta-classes")
are for -- to separate out just the parts you want to be different. And
currently, I don't see any reason to merge instances of STRUCTURE-OBJECT
in with those of STANDARD-OBJECT [yes, I know, "STRUCTURE-OBJECT" is a bit
of a neolgism, but one needs the term].
-- JonL --
∂01-Mar-89 2055 CL-Cleanup-mailer Issue EQUAL-STRUCTURE
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 89 20:55:36 PST
Date: Tue 28 Feb 89 13:44:16-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue EQUAL-STRUCTURE
To: JonL@LUCID.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12474359674.19.IIM@ECLA.USC.EDU>
> Date: Fri, 24 Feb 89 01:46:12 PST
> From: Jon L White <jonl@lucid.com>
>
> Kim, don't you have something turned around here? Previous mail referred to
> CLtL p81 to show that defstruct instances should be descended componentwise
> by EQUALP. This is not a statement about classes in general -- just about
> structure-class, and its historic meaning under EQUALP. Thus the Hawaii
> amendment was an *incompatible* change (which has already raised some
> question in Lucid's customer land!). This incompatible change unfortunately
> does nothing at all towards supplying the "mechanisms" you call for, and in
> fact breaks some existing code (in a very inscrutable way).
I stand by what I said. I believe you yourself have taken a position on some
issues that the status quo is wrong and needs to be fixed.
> Given the failure to make EQUALP generic, wouldn't it be far better to leave
> it alone and not make backwards-incompatible changes which do no one any
> good?
See new Issue EQUALP-GENERIC, coming soon to a mailbox near you.
kab
-------
∂04-Mar-89 1123 CL-Cleanup-mailer MERGE-PATHNAMES-DIRECTORY:EXTEND
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 4 Mar 89 11:22:37 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Sat, 4 Mar 89 13:20:19 CST id AA06415 for cl-cleanup@sail.stanford.edu
Posted-Date: Sat, 4 Mar 89 13:18:42 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA12921; Sat, 4 Mar 89 13:18:42 CST
Date: Sat, 4 Mar 89 13:18:42 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903041918.AA12921@pavo.src.honeywell.com>
To: cl-cleanup@sail.stanford.edu
Subject: MERGE-PATHNAMES-DIRECTORY:EXTEND
I understand that there may be a proposal that deals with this topic under
discussion in Cleanup, if so I'm willing to retract this submission.
Issue: MERGE-PATHNAMES-DIRECTORY
References: MERGE-PATHNAMES (p415), MAKE-PATHNAME (p416),
PATHNAME-DIRECTORY (p417), DIRECTORY-NAMESTRING (p417)
Category: CHANGE
Edit history: 03-Mar-89, Version 1 by ALarson
Problem description:
Merging of pathname components currently only supports complete
replacement. While this is satisfactory for "simple" components such as
type and version, the directory component on most modern operating systems
must describe a hierarchical directory structure and as such could benefit
from a more sophisticated merging policy.
For example; many large software packages exist in a collection of
directories that are related in a specific way starting at an arbitrary
location in the directory hierarchy (e.g. the FOO package may be
structured with ....foo/src, ....foo/bin, ....foo/doc, etc. where "...."
is some arbitrary directory path). The current specification of
MERGE-PATHNAMES does not permit the two parts of the directory component
to be specified separately in an implementation independent manner such
that MERGE-PATHNAMES could construct the entire directory path.
Proposal MERGE-PATHNAMES-DIRECTORY:EXTEND
Introduce the concept of an "absolute" pathname and a "relative" pathname.
An absolute pathname is one that starts at the beginning (or top) of the
host file system, a relative pathname is one which starts at an
unspecified location. A relative pathname must be merged with a absolute
pathname before it can be used to reference a file.
Specify that when the PATHNAME (first) argument to MERGE-PATHNAMES is a
relative pathname, the directory component of the DEFAULTS (second)
argument will appear first in the directory component of the resulting
pathname, followed by the directory component of the PATHNAME argument.
If the PATHNAME argument is an absolute pathname, then the directory
component of the resulting pathname will be the same as the directory
component of the PATHNAME argument.
Extend MAKE-PATHNAME:
The value specified for the :DIRECTORY keyword may be a list of keywords
and strings that denote the directory components in the directory path.
If the list begins with the keyword :ABSOLUTE the resulting pathname is
absolute, if the list begins with the keyword :RELATIVE then the
resulting pathname is relative. The results are implementation defined
if the list does not begin with one the keywords :RELATIVE or :ABSOLUTE.
In addition to :ABSOLUTE and :RELATIVE, an implementation may permit
additional keywords to appear in the directory list. The following
keywords, if they are accepted will have the following meaning; :WILD
matches all directories at the given location in the directory path, :UP
specifies that when MERGE-PATHNAMES is applied, one directory will be
eliminated from the resulting directory path, and :WILD-INFERIORS
which matches all directories below the point at which the
:WILD-INFERIORS keyword appears in the directory path.
<<< There should be a way to deal with UNIX style pathnames where
:UP is not strictly syntactic (i.e. it may depend on the file system.
A keyword dealing with this sort of thing would have to be maintained
until TRUENAME was gotten. I don't have a good candidate name for it
however. >>>
Introduce a new function;
PATHNAME-ABSOLUTE-P path
Path should be pathname, PATHNAME-ABSOLUTE-P returns true if path is an
absolute pathname, and false otherwise.
Specify that PATHNAME-DIRECTORY returns a list of the directory
componentsfor the given pathname. If pathname is an absolute pathname,
then the CAR of the list will be :ABSOLUTE, otherwise it will be
:RELATIVE. The results are undefined if the return value is modified.
Test Cases/Examples:
(setq abs-1 (MAKE-PATHNAME :DIRECTORY '(:ABSOLUTE "a")))
(setq abs-2 (MAKE-PATHNAME :DIRECTORY '(:ABSOLUTE "b")))
(setq rel-1 (MAKE-PATHNAME :DIRECTORY '(:RELATIVE "c")))
(setq rel-2 (MAKE-PATHNAME :DIRECTORY '(:RELATIVE "d"")))
(PATHNAME-DIRECTORY (MERGE-PATHNAMES abs-1 abs-2)) => (:ABSOLUTE "a")
(PATHNAME-DIRECTORY (MERGE-PATHNAMES abs-1 rel-1)) => (:ABSOLUTE "a")
(PATHNAME-DIRECTORY (MERGE-PATHNAMES rel-1 abs-1)) => (:ABSOLUTE "a" "c")
(PATHNAME-DIRECTORY (MERGE-PATHNAMES rel-1 rel-2)) => (:RELATIVE "d" "c")
(NOT (PATHNAME-ABSOLUTE-P abs-1)) => NIL
(PATHNAME-ABSOLUTE-P rel-1) => NIL
Rationale:
Current practice:
Allegro ExCL uses the same representations as descrived in this proposal,
and lucid and Symbolics Genera (presumably TI lispm as well) are very
close. Allegro CL and Symbolics Genera 7.2 already perform merging as
described in this proposal (which is clearly not legal CLtL). KCL, VAXLISP
2.1 and LUCID v?? do pathname directory merging as described in CLtL.
Symbolics Genera, LUCID, KCL, and Allegro already return lists from
PATHNAME-DIRECTORY, VAXLISP returns a string. Symbolics Genera currently
does pathname canonicalization for components specified in calls to
make-pathname, and reverses the canonicalization in the pathname-*
functions, but the intermediate pathname has the case of the components
inverted (at least for BSD 4.2 style pathnames).
PATHNAME-DIRECTORY results
Absolute Relative
KCL (unix) (:ROOT . strings) (strings)
Franz Allegro (unix) (:ABSOLUTE . strings) (:RELATIVE . strings)
Symbolics (lispm) (strings) (:RELATIVE . strings)
Lucid (unix) (strings) (:RELATIVE . strings)
Cost to Implementors:
Unknown, but not likely to be excessive.
Cost to Users:
Minimal. This is an imcompatible change in that pathname merging will no
longer always en mass replace the directory component, however portable
programs can currently only be using absolute pathnames whose behaviour
remans unchanged. The return value of PATHNAME-DIRECTORY is undefined now,
this proposal would make it defined. Although this could break existing
programs, they are already not portable.
Cost of non-adoption:
Manipulation of structured directory components will continue to be
difficult/implementation specific.
Benefits:
Manipulating structured directory components will be easier, and the
pathname functions will more accurately model existing file system
structure.
Esthetics:
None.
Discussion:
∂04-Mar-89 1740 CL-Cleanup-mailer Issue EQUALP-GENERIC
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 89 17:40:18 PST
Date: Sat 4 Mar 89 17:37:32-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue EQUALP-GENERIC
To: gregor.pa@XEROX.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, iim@ECLA.USC.EDU
Message-ID: <12475450716.30.IIM@ECLA.USC.EDU>
> Date: Wed, 1 Mar 89 19:50 PST
> From: Gregor.pa@Xerox.COM
>
> > An error is signaled on an attempt to add a method on any built-in class.
>
> ... I think the first is just covered by one of the principles outlined in
> chapter 3. ...
Yes. I haven't gotten Chapter 3 assimilated into my thinking yet.
> > Adding a method on a class after ALLOCATE-INSTANCE has been called on the
> > class has undefined consequences.
>
> {This} seems well intentioned but unreasonable. For one thing, some
> implementations may call allocate-instance before defclass returns. For
> another, it seems too painful to suggest that in order to define such a
> method you have to boot your lisp first. If this is really the only way the
> rest of the proposal can hold together, I think we need to reconsider the
> proposal.
I agree this is a serious weak point. Clearly, something needs to be said here
about the problem of breaking existing data structures by redefining the
functions they were built with. The restriction I wrote was intended mostly as
a place-holder while we try to come up with something better.
kab
-------
∂04-Mar-89 1741 CL-Cleanup-mailer Issue EQUAL-STRUCTURE
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 89 17:41:25 PST
Date: Sat 4 Mar 89 17:39:06-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue EQUAL-STRUCTURE
To: JonL@LUCID.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, iim@ECLA.USC.EDU
Message-ID: <12475451000.30.IIM@ECLA.USC.EDU>
> Date: Wed, 1 Mar 89 20:25:00 PST
> From: Jon L White <jonl@lucid.com>
>
> But the issue here is whether the fix is:
> (1) to drastically rip up the current default behaviour, or
> (2) to provide mechanisms that allow users to modify behaviour
> [and presumably, he gets the "default" if he doesn't do so].
> I've been favoring (2) over (1).
You're making me sound like an ogre. I certainly favor allowing users to
modify behaviour. What we disagree about is what the default behaviour should
be. I firmly believe that specifying component-wise processing as the default
for any protocol applicable to user defined classes is wrong. Without an
understanding of a class there is no way to know which features of an instance
are 'interesting' and which are merely artifacts of the implementation, or even
how to find the interesting features (they may not be stored as elements in the
instance).
I don't plan on saying anything further on this issue. I think we've both
presented our arguments, and its now beginning to sound like theological
debate. If you want us to modify/retract the decision made in Hawaii, generate
a cleanup issue and we can all vote on it.
kab
-------
∂06-Mar-89 1007 CL-Cleanup-mailer Re: Issue EQUAL-STRUCTURE
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 6 Mar 89 10:05:52 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa00906; 6 Mar 89 16:53 GMT
Date: Mon, 6 Mar 89 17:21:27 GMT
Message-Id: <19592.8903061721@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue EQUAL-STRUCTURE
To: "Kim A. Barrett" <IIM@ecla.usc.edu>,
JonL <@sail.stanford.edu:JonL@lucid.com>
In-Reply-To: Kim A. Barrett's message of Sat 4 Mar 89 17:39:06-PST
Cc: cl-cleanup@sail.stanford.edu
> I firmly believe that specifying component-wise processing as the default
> for any protocol applicable to user defined classes is wrong. Without an
> understanding of a class there is no way to know which features of
> an instance are 'interesting' and which are merely artifacts of the
> implementation, or even how to find the interesting features (they
> may not be stored as elements in the instance).
I know I shouldn't enter such debates at such a late date, but I don't
think this issue is as clear-cut as some seem to believe. While what
Kim says about instances is true, we have to remember that that we're
talking about EQUALP. EQUALP isn't supposed to do the one true right
thing; it's just supposed to be a sometimes useful combination. And
no one has to use it when it's inappropriate. Many users want an
equality comparison that descends structs, and they used to have one
(thought they may not have known it).
The whole argument turns around structs being user-defined classes.
After all, we're all willing to allow EQUALP on lists; and even for
lists there's no way to be sure what parts are really significant
(because, as always, this information is in the programmer's head)
or where all parts are kept (hash tables work for lists too).
But consistency with instances of classes with metaclass standard
class is just one of the factors we have to consider. Is it better
(or more useful) to make struct classes be like standard classes
minus some flexibility or to make them like structures in the old
sense plus the ability to define methods?
-- Jeff
∂06-Mar-89 1445 CL-Cleanup-mailer Issue: OPTIMIZE-SAFETY (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 14:45:06 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551643; Mon 6-Mar-89 17:42:39 EST
Date: Mon, 6 Mar 89 17:42 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: OPTIMIZE-SAFETY (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890306174235.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Sorry this is last-minute, but I believe it to be important.
-kmp
-----
Issue: OPTIMIZE-SAFETY
Forum: Cleanup
References: OPTIMIZE declaration (p160),
Issue ERROR-TERMINOLOGY
Category: CLARIFICATION/CHANGE
Edit history: 6-Mar-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL permits implementations to ignore OPTIMIZE declarations,
yet the new error terminology has a term ``should signal''
which guarantees that certain errors will be signalled in highest
safety.
This situation is at odds with the desire on the part of some vendors
to provide highly delivery configurations for Common Lisp, which
are streamlined to be small and fast at the expense of error checking.
If an implementation is permitted to start out in low safety mode,
and is also permitted to ignore OPTIMIZE SAFETY declarations, then
the meaning of ``should signal'' is called into question.
Proposal (OPTIMIZE-SAFETY:START-SAFE-OR-HEED-OPTIMIZE):
1. Define the initial safety setting of an implementation's
OPTIMIZE declarations to be implementation dependent. Conforming
implementations must document the initial setting.
2. Require every implementation to do at least one (and possibly
both) of the following:
a. Start in highest safety mode.
b. Not ignore the OPTIMIZE declaration.
Put another way, an implementation implementation which starts
out in ``unsafe'' mode is prohibited from ignoring OPTIMIZE
declarations that would allow the programmer to declare code
to require ``safe'' treatment.
Rationale:
1. This allows a particular implementation (or a particular core-image
that is part of an implementation family) to be naturally biased
for delivery.
2. This makes sure that situations like
(LOCALLY (DECLARE (OPTIMIZE (SPEED 0) (SAFETY 3)))
...)
will reliably select "safe code" even in implementations that are
initially biased for speed over safety.
Current Practice:
Symbolics Genera and Symbolics Cloe conform to the stated proposal.
Cost to Implementors:
Considerable error checking would have to be added to upgrade any
non-conforming implementations, if in fact there are any.
Another alternative would be for a non-conforming implementation to
identify itself as a special "subset" of Common Lisp that does not
support those options. That would require no work, but would require
careful documentation in order for users to understand the consequences.
However, such a subset could easily notice when the programmer was
trying to enter a high safety mode explicitly, and could warn that he
was probably going to lose.
Cost to Users:
None. Most users will regard this as a bug fix.
Cost of Non-Adoption:
Any useful interpretation of ``should signal'' will be in severe
jeopardy.
Benefits:
More truth in packaging.
Aesthetics:
Adding this kind of reliability presumably improves aesthetics.
Discussion:
Pitman supports this proposal.
∂06-Mar-89 1717 CL-Cleanup-mailer [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 17:17:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551822; Mon 6-Mar-89 20:15:04 EST
Date: Mon, 6 Mar 89 20:14 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
To: Guy Steele <gls@Think.COM>, Dave.Touretzky@B.GP.CS.CMU.EDU
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8902271810.AA18268@verdi.think.com>
Message-ID: <19890307011451.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I see no reason why this can't be handled by programming in Lisp
rather than adding new syntax to FORMAT.
Guy: I'm still pissed at you, even after more than ten years, for
adding programming language features to FORMAT after we had all
agreed not to do that. OK, I admit I'm still speaking to you, and
I admit that I use the features myself. But I still think they
are wrong.
∂06-Mar-89 1831 CL-Cleanup-mailer Re: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 18:30:47 PST
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 6 Mar 89 21:27:35 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Guy Steele <gls@Think.COM>, cl-cleanup@sail.stanford.edu
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: Re: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
In-reply-to: Your message of Mon, 06 Mar 89 20:14:00 -0500.
<19890307011451.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 06 Mar 89 21:27:21 EST
Message-ID: <5529.605240841@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU
Okay, let me state my proposal a different way:
The current ~P format directive is lame; it should either be fixed or
flushed. It cannot even handle all the standard plural forms (those
requiring "es" endings), not to mention the non-standard plurals
(mouse/mice, etc.) And of course, it's only useful for English.
While it's true, as Moon points out, that we can flush the number-dependent
conditional altogether and replace it with Lisp code, I think the resulting
code would be more verbose and cumbersome than what a properly designed
format directive offers. Generating number-dependent strings (which
includes things like the "is/are" distinction and possessives, as well as
plural suffixes) is a pretty common operation, so it would be of some
benefit to streamline it.
My proposal, which would work for many languages besides English, is to
replace ~P with a new conditional form which would select the singular
case only when the argument was EQL to 1.
~:@[singular~;plural~]
Negative numbers would thus automatically use the plural form, as is
correct in English. The standard ~[] conditional cannot handle negatives
at all. Compare the following code fragment using Lisp code (as Moon
suggests) vs. the proposed pluralization operator:
(defun report (n)
(format t "~&There ~A ~D bad ~A to be fixed."
(if (eql n 1) "is" "are")
n
(if (eql n 1) "mouse" "mice")))
(defun report (n)
(format t
"~&There ~:@[is~;are~]~:* ~D~:* bad ~:@[mouse~;mice] to be fixed." n))
Of course, it would be better to use ~P to name this new operator; that way
we could use ~:P to combine it with the ~:* operation. In fact, it would
be most convenient to make the : modifier back up one arg AFTER the
directive has been performed, and the @ modifier back up one arg BEFORE
performing the directive. Then the above example would look like this:
(defun report (n)
(format t
"~&There ~:P[is~;are~] ~D bad ~@P[mouse~;mice] to be fixed." n))
The only reason not to usurp ~P for this number-dependent conditional would
be for compatibility with existing code.
-- Dave
∂06-Mar-89 1911 CL-Cleanup-mailer Re: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 18:55:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551880; Mon 6-Mar-89 21:52:37 EST
Date: Mon, 6 Mar 89 21:52 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
To: Dave.Touretzky@cs.cmu.edu
cc: Guy Steele <gls@Think.COM>, cl-cleanup@sail.stanford.edu
In-Reply-To: <5529.605240841@DST.BOLTZ.CS.CMU.EDU>
Message-ID: <19890307025214.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 06 Mar 89 21:27:21 EST
From: Dave.Touretzky@B.GP.CS.CMU.EDU
My proposal, which would work for many languages besides English, is to
replace ~P with a new conditional form which would select the singular
case only when the argument was EQL to 1.
~:@[singular~;plural~]
Yes, this is a reasonable proposal. It wasn't clear to me in the midst of
all the verbiage before that this was what you were proposing. When I say
it's reasonable, that doesn't mean I'm enthusiastic about it, simply because
I am not enthusiastic about doing anything to FORMAT.
Of course, it would be better to use ~P to name this new operator; that way
we could use ~:P to combine it with the ~:* operation.
There are plenty of other letters available (although Dick Waters is using
some of them in his portable pretty-printer). On the other hand, since you
need to enclose something it's nice to use brackets. I know, we could
say that : and @ aren't enough modifiers and introduce a third one. Some
possibilities (I forgot to check whether Waters has already staked a claim
to any of these) are !, +, ., /, =, _, and `. I skipped " and \ because
of their significance in string syntax. + looks the best to me.
∂06-Mar-89 1921 CL-Cleanup-mailer Re: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 19:21:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551881; Mon 6-Mar-89 21:53:46 EST
Date: Mon, 6 Mar 89 21:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
To: Dave.Touretzky@cs.cmu.edu
cc: Guy Steele <gls@Think.COM>, cl-cleanup@sail.stanford.edu
In-Reply-To: <5529.605240841@DST.BOLTZ.CS.CMU.EDU>
Supersedes: <19890307025214.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890307025332.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 06 Mar 89 21:27:21 EST
From: Dave.Touretzky@B.GP.CS.CMU.EDU
My proposal, which would work for many languages besides English, is to
replace ~P with a new conditional form which would select the singular
case only when the argument was EQL to 1.
~:@[singular~;plural~]
Yes, this is a reasonable proposal. It wasn't clear to me in the midst of
all the verbiage before that this was what you were proposing. When I say
it's reasonable, that doesn't mean I'm enthusiastic about it, simply because
I am not enthusiastic about doing anything to FORMAT.
Of course, it would be better to use ~P to name this new operator; that way
we could use ~:P to combine it with the ~:* operation.
There are plenty of other letters available (although Dick Waters is using
some of them in his portable pretty-printer). On the other hand, since you
need to enclose something it's nice to use brackets. I know, we could
say that : and @ aren't enough modifiers and introduce a third one. Some
possibilities (I forgot to check whether Waters has already staked a claim
to any of these) are !, +, ., /, =, _, and `. I skipped " and \ because
of their significance in string syntax. + looks the best to me, except it
is already in use as a redundant character in prefix parameters. = is
second-best.
∂06-Mar-89 2031 CL-Cleanup-mailer Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 20:31:31 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551906; Mon 6-Mar-89 23:29:12 EST
Date: Mon, 6 Mar 89 23:29 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890306232902.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Well, no one else beat me to it so I finally got around to writing up one
of the several needed proposals on what functions should signal what errors.
Let me emphasize that even though this covers a subset of the functions in
CLtL, it is still both meaningful and useful to vote on it separately. If
we had only proposals for handling of errors in numbers and files/streams
that would cover a very large class of cases.
This being a long proposal, please keep your comments focused. Preferrably
just requests for specific changes in wording with a brief rationale for the
change. I am not firmly wedded to any of the positions I've taken here --
I just felt it necessary to take -some- position. I patterned this pretty
directly after a document I passed out several meetings ago, but I got very
little feedback on that document, so I don't know if it was controversial.
-kmp
----
Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER
Forum: Cleanup
References: Numbers (pp193-232),
S:>kmp>cl>conditions>revision-18-notes.text.34
(formerly S:>kmp>cl-conditions.text.34),
Category: CHANGE
Edit history: 06-Mar-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
In many cases, CLtL specifies ``is an error'' situations for functions
in places that programmers would prefer to see an error signalled.
Reliably signalling an error accomplishes two things...
- It eases the development process by making it easier to notice errors
in a timely fashion.
- It makes it easier for code to reliably handle errors at runtime,
leading to greater robustness in delivered applications.
Proposal (ERROR-CHECKING-IN-NUMBERS-CHAPTER:SCARECROW): - a straw man...
ABS should signal TYPE-ERROR if its argument is not type NUMBER.
ACOS should signal TYPE-ERROR if its argument is not type NUMBER.
ACOS might signal ARITHMETIC-ERROR.
ACOSH should signal TYPE-ERROR if its argument is not type NUMBER.
ACOSH might signal ARITHMETIC-ERROR.
ASH should signal TYPE-ERROR if either argument is not type INTEGER.
ASH might signal ARITHMETIC-ERROR.
ASIN should signal TYPE-ERROR if its argument is not type NUMBER.
ASIN might signal ARITHMETIC-ERROR.
ASINH should signal TYPE-ERROR if its argument is not type NUMBER.
ASINH might signal ARITHMETIC-ERROR.
ATAN should signal TYPE-ERROR if exactly one argument is given and that
argument is not type NUMBER.
ATAN should signal TYPE-ERROR if exactly two arguments are given and
either argument is not type (AND NUMBER (NOT COMPLEX)).
ATAN might signal ARITHMETIC-ERROR.
ATANH should signal TYPE-ERROR if its argument is not type NUMBER.
ATANH might signal ARITHMETIC-ERROR.
BOOLE should signal TYPE-ERROR if its first argument is not type
(MEMBER #.BOOLE-CLR #.BOOLE-SET #.BOOLE-1 #.BOOLE-2
#.BOOLE-C1 #.BOOLE-C2 #.BOOLE-AND #.BOOLE-IOR
#.BOOLE-XOR #.BOOLE-EQV #.BOOLE-NAND #.BOOLE-NOR
#.BOOLE-ANDC1 #.BOOLE-ANDC2 #.BOOLE-ORC1 #.BOOLE-ORC2)
BOOLE should signal TYPE-ERROR if either its second or third
argument is not type INTEGER.
BYTE should signal TYPE-ERROR if either argument is not type INTEGER.
BYTE-POSITION might signal TYPE-ERROR if its argument is not a byte
specifier (something that was returned by the BYTE
function). Note that byte specifiers are not required
to be disjoint from other types, so this error checking
is only heuristic.
BYTE-SIZE might signal TYPE-ERROR if its argument is not a byte
specifier (something that was returned by the BYTE
function). Note that byte specifiers are not required
to be disjoint from other types, so this error checking
is only heuristic.
CEILING should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
CEILING should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
CEILING should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
CEILING might signal ARITHMETIC-ERROR.
COMPLEX should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
COMPLEX should signal TYPE-ERROR if its second argument is provided
but is not type (AND NUMBER (NOT COMPLEX)).
CONJUGATE should signal TYPE-ERROR if its argument is not type NUMBER.
CIS should signal TYPE-ERROR if its argument is not type
(AND NUMBERP (NOT COMPLEX)).
CIS might signal ARITHMETIC-ERROR.
COS should signal TYPE-ERROR if its argument is not type NUMBER.
COS might signal ARITHMETIC-ERROR.
COSH should signal TYPE-ERROR if its argument is not type NUMBER.
COSH might signal ARITHMETIC-ERROR.
DECF might signal SYNTAX-ERROR at semantic processing time.
DECF should signal TYPE-ERROR at runtime if the variable to be
incremented does not have a value of type NUMBER.
DECF might signal ARITHMETIC-ERROR at runtime.
DECODE-FLOAT should signal TYPE-ERROR if its argument is not type FLOAT.
DENOMINATOR should signal TYPE-ERROR if its argument is not type RATIONAL.
DEPOSIT-FIELD should signal TYPE-ERROR if its first argument is not type
INTEGER.
DEPOSIT-FIELD might signal TYPE-ERROR if its second argument is not a
bytespec (something returned by BYTE). Note that byte
specifiers are not required to be disjoint from other types,
so this error checking is only heuristic.
DEPOSIT-FIELD should signal TYPE-ERROR if its third argument is not type
INTEGER.
DPB should signal TYPE-ERROR if its first argument is not type INTEGER.
DPB might signal TYPE-ERROR if its second argument is not a bytespec
(something returned by BYTE). Note that byte specifiers are not
required to be disjoint from other types, so this error checking
is only heuristic.
DPB should signal TYPE-ERROR if its third argument is not type INTEGER.
EVENP should signal TYPE-ERROR if its argument is not type INTEGER.
FCEILING should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
FCEILING should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
FCEILING should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
FCEILING might signal ARITHMETIC-ERROR.
FFLOOR should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
FFLOOR should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
FFLOOR should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
FFLOOR might signal ARITHMETIC-ERROR.
FLOOR should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
FLOOR should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
FLOOR should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
FLOOR might signal ARITHMETIC-ERROR.
FROUND should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
FROUND should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
FROUND should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
FROUND might signal ARITHMETIC-ERROR.
FTRUNCATE should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
FTRUNCATE should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
FTRUNCATE should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
FTRUNCATE might signal ARITHMETIC-ERROR.
GCD should signal TYPE-ERROR if any argument is not type INTEGER.
GCD might signal ARITHMETIC-ERROR.
EXP should signal TYPE-ERROR if its argument is not type NUMBER.
EXP might signal ARITHMETIC-ERROR.
EXPT should signal TYPE-ERROR if either argument is not type NUMBER.
EXPT might signal ARITHMETIC-ERROR. e.g., (EXPT 0 0.0)
FLOAT should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
FLOAT should signal TYPE-ERROR if its second argument is supplied
but is not type FLOAT.
FLOAT might signal ARITHMETIC-ERROR.
FLOAT-DIGITS should signal TYPE-ERROR if its argument is not type FLOAT.
FLOAT-PRECISION should signal TYPE-ERROR if its argument is not type FLOAT.
FLOAT-RADIX should signal TYPE-ERROR if its argument is not type FLOAT.
FLOAT-SIGN should signal TYPE-ERROR if its first argument is not type
FLOAT.
FLOAT-SIGN should signal TYPE-ERROR if its second argument is supplied
but is not type FLOAT.
INCF might signal SYNTAX-ERROR at semantic processing time.
INCF should signal TYPE-ERROR at runtime if the variable to be
incremented does not have a value of type NUMBER.
INCF might signal ARITHMETIC-ERROR at runtime.
INTEGER-DECODE-FLOAT should signal TYPE-ERROR if its argument is not
type FLOAT.
INTEGER-LENGTH should signal TYPE-ERROR if its argument is not type INTEGER.
IMAGPART should signal TYPE-ERROR if its argument is not type NUMBER.
ISQRT should signal TYPE-ERROR if its argument is not type (INTEGER 0).
ISQRT might signal ARITHMETIC-ERROR.
LCM should signal TYPE-ERROR if any argument is not type INTEGER.
LCM might signal ARITHMETIC-ERROR.
LDB might signal TYPE-ERROR if its first argument is not a bytespec
(something returned by BYTE). Note that byte specifiers are not
required to be disjoint from other types, so this error checking
is only heuristic.
LDB should signal TYPE-ERROR if its second argument is not type INTEGER.
LDB-TEST might signal TYPE-ERROR if its first argument is not a bytespec
(something returned by BYTE). Note that byte specifiers are not
required to be disjoint from other types, so this error checking
is only heuristic.
LDB-TEST should signal TYPE-ERROR if its second argument is not type INTEGER.
LOG should signal TYPE-ERROR if either argument is not type NUMBER.
LOG might signal ARITHMETIC-ERROR.
LOGAND should signal TYPE-ERROR if any argument is not type INTEGER.
LOGANDC1 should signal TYPE-ERROR if either argument is not type INTEGER.
LOGANDC2 should signal TYPE-ERROR if either argument is not type INTEGER.
LOGBITP should signal TYPE-ERROR if its first argument is not type
(INTEGER 0).
LOGBITP should signal TYPE-ERROR if its second argument is not type
INTEGER.
LOGCOUNT should signal TYPE-ERROR error if its argument is not type INTEGER.
LOGEQV should signal TYPE-ERROR if any argument is not type INTEGER.
LOGIOR should signal TYPE-ERROR if any argument is not type INTEGER.
LOGNAND should signal TYPE-ERROR if either argument is not type INTEGER.
LOGNOR should signal TYPE-ERROR if either argument is not type INTEGER.
LOGNOT should signal TYPE-ERROR error if its argument is not type INTEGER.
LOGORC1 should signal TYPE-ERROR if either argument is not type INTEGER.
LOGORC2 should signal TYPE-ERROR if either argument is not type INTEGER.
LOGTEST should signal TYPE-ERROR if either argument is not type INTEGER.
LOGXOR should signal TYPE-ERROR if any argument is not type INTEGER.
MAKE-RANDOM-STATE should signal TYPE-ERROR if an argument is supplied
but is not type (OR (MEMBER NIL T) RANDOM-STATE).
MASK-FIELD might signal TYPE-ERROR if its first argument is not a bytespec
(something returned by BYTE). Note that byte specifiers are not
required to be disjoint from other types, so this error checking
is only heuristic.
MASK-FIELD should signal TYPE-ERROR if its second argument is not type
INTEGER.
MAX should signal TYPE-ERROR if any argument is not type
(AND NUMBERP (NOT COMPLEX)).
MAX might signal ARITHMETIC-ERROR.
MIN should signal TYPE-ERROR if any argument is not type
(AND NUMBERP (NOT COMPLEX)).
MIN might signal ARITHMETIC-ERROR.
MINUSP should signal TYPE-ERROR if its argument is not type
(AND NUMBER (NOT COMPLEX)).
MOD should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
MOD should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
MOD should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
MOD might signal ARITHMETIC-ERROR.
NUMERATOR should signal TYPE-ERROR if its argument is not type RATIONAL.
ODDP should signal TYPE-ERROR if its argument is not type INTEGER.
PHASE should signal TYPE-ERROR if its argument is not type NUMBER.
PHASE might signal ARITHMETIC-ERROR.
PLUSP should signal TYPE-ERROR if its argument is not type
(AND NUMBER (NOT COMPLEX)).
RANDOM should signal TYPE-ERROR if its first argument is not
type (INTEGER 1).
RANDOM should signal TYPE-ERROR if its second argument is supplied
but is not type RANDOM-STATE.
RANDOM-STATE-P will never signal an error.
RATIONAL should signal TYPE-ERROR if its argument is not type
(AND NUMBER (NOT COMPLEX)).
RATIONAL might signal ARITHMETIC-ERROR.
RATIONALIZE should signal TYPE-ERROR if its argument is not type
(AND NUMBER (NOT COMPLEX)).
RATIONALIZE might signal ARITHMETIC-ERROR.
REALPART should signal TYPE-ERROR if its argument is not type NUMBER.
REM should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
REM should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
REM should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
REM might signal ARITHMETIC-ERROR.
ROUND should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
ROUND should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
ROUND should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
ROUND might signal ARITHMETIC-ERROR.
SCALE-FLOAT should signal TYPE-ERROR if its first argument is not
type FLOAT.
SCALE-FLOAT should signal TYPE-ERROR if its second argument is not
type INTEGER.
SIGNUM should signal TYPE-ERROR if its argument is not type NUMBER.
SIN should signal TYPE-ERROR if its argument is not type NUMBER.
SIN might signal ARITHMETIC-ERROR.
SINH should signal TYPE-ERROR if its argument is not type NUMBER.
SINH might signal ARITHMETIC-ERROR.
SQRT should signal TYPE-ERROR if its argument is not type NUMBER.
SQRT might signal ARITHMETIC-ERROR.
TAN should signal TYPE-ERROR if its argument is not type NUMBER.
TAN might signal ARITHMETIC-ERROR.
TANH should signal TYPE-ERROR if its argument is not type NUMBER.
TANH might signal ARITHMETIC-ERROR.
TRUNCATE should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
TRUNCATE should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
TRUNCATE should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
TRUNCATE might signal ARITHMETIC-ERROR.
ZEROP should signal TYPE-ERROR if its argument is not type NUMBER.
* should signal TYPE-ERROR if any argument is not type NUMBER.
* might signal ARITHMETIC-ERROR.
+ should signal TYPE-ERROR if any argument is not type NUMBER.
+ should signal TYPE-ERROR if any argument is not type NUMBER.
+ might signal ARITHMETIC-ERROR.
- should signal TYPE-ERROR if any argument is not type NUMBER.
- might signal ARITHMETIC-ERROR.
/ should signal TYPE-ERROR if any argument is not type NUMBER.
/ should signal DIVISION-BY-ZERO if any divisor argument is zero.
/ might signal ARITHMETIC-ERROR.
/= should signal type-error if any argument is not type NUMBER.
/= might signal ARITHMETIC-ERROR.
1+ should signal TYPE-ERROR if any argument is not type NUMBER.
1+ might signal ARITHMETIC-ERROR.
1- should signal TYPE-ERROR if any argument is not type NUMBER.
1- might signal ARITHMETIC-ERROR.
< should signal TYPE-ERROR if any argument is not type
(AND NUMBER (NOT COMPLEX)).
< might signal ARITHMETIC-ERROR.
<= should signal TYPE-ERROR if any argument is not type
(AND NUMBER (NOT COMPLEX)).
<= might signal ARITHMETIC-ERROR.
= should signal TYPE-ERROR if any argument is not type NUMBER.
= might signal ARITHMETIC-ERROR.
> should signal TYPE-ERROR if any argument is not type
(AND NUMBER (NOT COMPLEX)).
> might signal ARITHMETIC-ERROR.
>= should signal TYPE-ERROR if any argument is not type
(AND NUMBER (NOT COMPLEX)).
>= might signal ARITHMETIC-ERROR.
Rationale:
This addresses the development and delivery concerns mentioned in the
Problem Description.
Current Practice:
Most implementations probably do not reliably signal the indicated
errors in safe code.
Cost to Implementors:
In implementations not providing the indicated error checking,
considerable work might need to be done.
The alternative is to identify the implementation as an "unsafe" subset.
However, while it is a "subset" in the sense that code that was developed
in it will run in the superset, it is important to understand that such
implementations are not simply "places you can run code that's been
thoroughly debugged in the full language" since such debugged code may
still depend on the reliable detection and handling of certain kinds of
errors.
Cost to Users:
Technically none. These are supposedly already all `is an error'
cases that people can't depend on.
Some users might be relying on an implementation not to signal a particular
error in compiled code. Such code is already not portable, however.
In some cases, where an implementation adds error checking that they
consider unnecessary, the user will need to add some OPTIMIZE proclamations.
Some users will see this as a bug fix.
Cost of Non-Adoption:
The error handling facilities will be a lot less useful.
Code that uses error handling will not port well.
Benefits:
Better development environments. More robust delivered applications.
Aesthetics:
Hopefully improved.
Discussion:
Pitman getting this level of detail is a good idea. He's ammenable to
specific changes if they improve the overall level of receptiveness to
the proposal.
Notes about how to proceed on this issue
(to be removed prior to final vote):
- Is anyone uncomfortable about the name ARITHMETIC-ERROR?
If so, can someone mathematically inclined suggest a better name?
`MATH-ERROR' or `NUMBER-ERROR' come to mind.
- In some of the cases of "might signal", it might be the case that
no signal should ever occur. Someone who's actually implemented these
functions might want to suggest that in some cases we can remove
this verbiage, or give examples of the circumstances under which the
condition might be signalled?
∂06-Mar-89 2053 CL-Cleanup-mailer Issue: FORMAT-PLURALS [was "pluralization: two proposals"]
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 20:53:02 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551920; Mon 6-Mar-89 23:50:15 EST
Date: Mon, 6 Mar 89 23:50 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-PLURALS [was "pluralization: two proposals"]
To: Masinter.PA@Xerox.COM
cc: Dave.Touretzky@cs.cmu.edu, CL-Cleanup@SAIL.Stanford.EDU
References: <8902272258.AA02864@pitney-bowes>,
<8902271810.AA18268@verdi.think.com>,
<3127.604575426@DST.BOLTZ.CS.CMU.EDU>,
<19890307011451.1.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<19890307025332.6.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<19890307025214.5.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<5529.605240841@DST.BOLTZ.CS.CMU.EDU>
Message-ID: <890306235009.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Even if nothing gets written up on this, I'm filing this issue under the
heading FORMAT-PLURALS for naming convenience.
∂07-Mar-89 1047 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 7 Mar 89 10:45:21 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06887; 7 Mar 89 18:04 GMT
Date: Tue, 7 Mar 89 18:32:46 GMT
Message-Id: <22896.8903071832@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: David N Gray <Gray%dsg.csc.ti.com@NSS.Cs.Ucl.AC.UK>
Cc: pierson <@multimax.encore.com:pierson@mist.encore.com>,
KMP@scrc-stony-brook.arpa, CL-Cleanup@sail.stanford.edu
> I notice that our reader calls CHAR-UPCASE on characters which the read
> table defines as possible constituents of a symbol name. Suppose that
> instead of a hard-coded call to CHAR-UPCASE, it FUNCALLed a function
> contained in the read table, with #'CHAR-UPCASE being the initial value
> in the standard read table. That would be a very simple change, but would
> give you all the flexibility you might want. The only drawback is that it
> could slow the reader down, since our call to CHAR-UPCASE is actually
> expanded inline now.
Hummm. I like this approach, but I'm not sure people will be happy
with a slower reader. Of course, the function call might skipped
in the "normal" case, and CHAR-UPCASE called in-line; and that may
be good enough.
I'm also somewhat uneasy about allowing arbitrary translations.
Suppose "a" is translated to "b". Does that mean PRINT should
escape any "a"s in print names? DO we have to restrict the set
of valid functions?
> I like the idea of doing things like this as keyword arguments to
> COPY-READTABLE, both to avoid inventing new function names and to protect
> the standard readtable from alteration. For example:
>
> (DEFPARAMETER *CASE-SENSITIVE-READTABLE*
> (COPY-READTABLE *READTABLE* NIL
> :SYMBOL-CHAR-TRANSLATION #'IDENTITY))
KMP writes;
Date: Wed, 22 Feb 89 14:13 EST
From: Kent M Pitman <KMP@arpa.scrc-stony-brook>
I would support such a proposal.
However, I would prefer to see CHARACTER spelled out. This won't be used
often enough to justify abbreviation.
OK. However, there are lots of "CHAR-" functions in Common Lisp,
so it could go either way.
Also, I'm not sure that the `SYMBOL' part of the name is warranted
or even a good idea. For example, this option might control whether
you had to write #\Control-\a or could get away with #\Control-a.
Obviously, that's a matter to be decided by the Characters
committee, but if we choose an overly specific name, we'll make
it harder for them to explain.
I'm happy to see the "SYMBOL" go, but I don't want to end up
creating confusion about when the translation occurs. I was
expecting it to happen at step 8, point 1 (CLtL, page 337).
Is that ok?
Symbolics has used the function name SET-CHARACTER-TRANSLATION for a
while and to my knowledge no one has complained that it did not
affect (for example) strings. As such, I'd prefer
(COPY-READTABLE *READTABLE* NIL :CHARACTER-TRANSLATION ...)
Good.
Providing no way to modify a readtable's character translation function
would avoid the problem of people modifying the standard readtable, but
it would probably also be a nuisance in other situations. My vote would be
for adding a setf-able function READTABLE-CHARACTER-TRANSLATION as well.
I prefer being able to set things when it's reasonable to do so,
and I'd like to have the function anyway so that I can call it
on a readtable and see what its translation function is.
-- Jeff
∂07-Mar-89 1054 CL-Cleanup-mailer [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 7 Mar 89 10:54:47 PST
Received: from fafnir.think.com by Think.COM; Tue, 7 Mar 89 13:23:05 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 7 Mar 89 13:24:43 EST
Received: by verdi.think.com; Tue, 7 Mar 89 13:21:27 EST
Date: Tue, 7 Mar 89 13:21:27 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903071821.AA02025@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: dick@wheaties.ai.mit.edu
Cc: gls@Think.COM, Dave.Touretzky@b.gp.cs.cmu.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 6 Mar 89 20:14 EST <19890307011451.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
Date: Mon, 6 Mar 89 20:14 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
I see no reason why this can't be handled by programming in Lisp
rather than adding new syntax to FORMAT.
Guy: I'm still pissed at you, even after more than ten years, for
adding programming language features to FORMAT after we had all
agreed not to do that. OK, I admit I'm still speaking to you, and
I admit that I use the features myself. But I still think they
are wrong.
Actually, on Tuesdays and Fridays I am pissed at myself for the same
reason. But I use them, too. More to the point, I still have not
seen an alternative that is more convenient. But I would be happy to
see a cleanup proposal to nuke lots of formatting widgies.
FORMAT and LOOP are both like Lay's Potato Chips: betcha can't eat just one!
To Dick Waters: actually, in the pretty-printer proposal, perhaps
FORMAT should not be the *only* interface to the pretty-printer?
Maybe there should be functions one can call as well?
--Guy
∂07-Mar-89 1135 CL-Cleanup-mailer [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 7 Mar 89 11:35:00 PST
Received: from fafnir.think.com by Think.COM; Tue, 7 Mar 89 14:14:22 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 7 Mar 89 14:16:05 EST
Received: by verdi.think.com; Tue, 7 Mar 89 14:12:53 EST
Date: Tue, 7 Mar 89 14:12:53 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903071912.AA02803@verdi.think.com>
To: Dave.Touretzky@cs.cmu.edu
Cc: Moon@stony-brook.scrc.symbolics.com, gls@Think.COM,
cl-cleanup@sail.stanford.edu
In-Reply-To: Dave.Touretzky@b.gp.cs.cmu.edu's message of Mon, 06 Mar 89 21:27:21 EST <5529.605240841@DST.BOLTZ.CS.CMU.EDU>
Subject: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]
I believe that some languages have special dual forms (for the case of
exactly two things). At the risk of hairing things up, allow me to propose
that there can be more than two clauses, and nonpositive numbers or
positive numbers that are too large use the last clause; if the first
clause ends with ~:; then that clause is for zero, and the others follow.
Hence:
(defun rats (x)
(format nil "I fixed ~!:@=!P[no~:;one~;both~;~*~D~] ~
~*~@:!P[mouse~;mice~]" x))
(rats -1) => "I fixed -1 mice"
(rats 0) => "I fixed no mice"
(rats 1) => "I fixed one mouse"
(rats 2) => "I fixed both mice" ;Note dual form in English!
(rats 3) => "I fixed 3 mice"
Hm. Maybe ~@; should terminate a clause that handles just negative
numbers.
(defun rodents (x)
(format nil "I fixed ~!:@=!P[~*~D~@;no~:;one~;both~;all the~] ~
~*~@:!P[mouse~;mice~]" x))
(rodents -1) => "I fixed -1 mice"
(rodents 0) => "I fixed no mice"
(rodents 1) => "I fixed one mouse"
(rodents 2) => "I fixed both mice" ;Note dual form in English!
(rodents 3) => "I fixed all the mice"
Um... Dave? DAVE? What are you doing with that stick? NO, MOON, NO!
AAAEIEAIAIEIIEIEIEIIIIIIEEIIEEEEEEEEEE!
∂07-Mar-89 1443 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 89 14:42:50 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 552470; Tue 7-Mar-89 17:40:29 EST
Date: Tue, 7 Mar 89 17:40 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890307174023.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
I'm crossing my fingers you'll think this is ready to ship to X3J13 for
a vote. Everyone might not agree on the same option, but hopefully it at
least adequately expresses the viable options at this point and we
can just get a show of hands to figure out whether to adopt one of these
two things or to just give up on the issue.
-kmp
-----
Issue: COERCE-INCOMPLETE
Reference: COERCE (p50)
Category: ADDITION/CHANGE
Edit history: Version 1 of COERCE-INCOMPLETE, 26-Feb-88 by M. Ida
Version 1 of COERCE-FROM-TYPE, 20-Jun-88 by Pitman
Version 2 of COERCE-INCOMPLETE, 21-Nov-88 by Pitman
(consolidate previous two proposals)
Version 3 of COERCE-INCOMPLETE, 07-Mar-89 by Pitman
(eliminate unpopular proposal, two new options)
Problem Description:
COERCE is difficult to extend because ambiguities arise about the
source type of the coercion.
For example, if the symbol STRING were permitted as a second argument
to coerce, as in (COERCE NIL 'STRING), there would be two posssible
return values: "" or "NIL". The choice would be arbitrary and would
have to be specified by the documentation. No matter which was chosen,
it would probably turn out to be a problem for some applications at
some times.
Another example is (COERCE (CHAR-CODE #\A) 'STRING). This might
return the same as (FORMAT NIL "~D" (CHAR-CODE #\A)) -- "65" in
most ASCII-based implementations -- or it might return "A". Again,
the choice would be arbitrary.
There is clear desire on the part of the user community to lift some of
the existing restrictions on arguments to COERCE, but because of legitimate
concerns about ambiguities, the Common Lisp designers have thus far
refused to do so.
Unfortunately, the failure of COERCE to handle these cases means it is
very difficult to learn to use COERCE. And the fact that COERCE is not
easily learned contributes to difficulty in learning Common Lisp because
instead of a single coercion operator with general purpose semantics, a
number of very special purpose coercion operators must be learned instead.
Some middle ground needs to be found, which neither compromises the
clear semantics and portable nature of COERCE nor complicates COERCE
in a way that makes it unlearnable.
Also, some people have expressed a desire for COERCE to be more
`symmetric.' Usually they seem to mean that they want it to be the case
that if (COERCE x y) works, then (COERCE (COERCE x y) (TYPE-OF x))
should also work. Although this is not an essential desire, it would
certainly be nice to achieve.
Proposal (COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION):
Define COERCE to accept the following equivalences:
1. (COERCE x 'STRING) == (STRING x)
2. (COERCE x 'PATHNAME) == (PATHNAME x)
3. (COERCE x 'RATIONAL) == (RATIONAL x)
Clarify that
4. (COERCE x 'FLOAT) == (FLOAT x)
Rationale:
Many users think of STRING, for example, as ``the way to coerce
something to a string'' and are baffled why COERCE and STRING
disagree on how to do this.
Such users think that if there's a moral battle to be waged
over how to coerce an object to a STRING, the battle has already
been lost by defining the STRING function -- that whatever
decision is made for STRING must also apply to COERCE for the
sake of simplicity.
Similar arguments can be made for PATHNAME, FLOAT, and RATIONAL.
Proposal (COERCE-INCOMPLETE:DEPRECATE):
Deprecate COERCE.
Rationale:
COERCE is not functionally necessary -- no operation that it does
cannot be done in some other way. As such, it is basically just
a matter of syntactic convenience, and perhaps isn't worth having
around if it will be the subject of endless debate. Deprecating
it would allow us to declare this issue a `dead end' and focus our
attention on matters of greater substance.
Current Practice:
Presumably No one implements either of the proposals at this time,
since none are compatible with CLtL.
Cost to Implementors:
COERCE: Small to moderate.
DEPRECATE: None.
Cost to Users:
COERCE: This is an incompatible change. (COERCE 'NIL 'STRING) => ""
but (STRING NIL) => "NIL". How many applications are impacted by
this change is not clear. It would be straightforward to shadow
COERCE with an alternate definition that did the old thing in
cases where people were worried. Once such cases have been
identified, rewriting
(COERCE X 'STRING)
as
(IF X (COERCE X 'STRING) "")
will suffice in most cases.
DEPRECATE: No immediate work would be needed, although many maintained
applications would get upgraded in order to use the primitives that
are `in vogue.'
Cost of Non-Adoption:
People will continue to see and debate the issues alluded to in
the Problem Description.
Benefits:
The cost of Non-Adoption will be avoided.
Aesthetics:
COERCE: Many people will probably see the idea of making
COERCE consistent with STRING, PATHNAME, FLOAT, and
RATIONAL as a clear improvement -- possibly outweighing
the costs of both an incompatible change and a decision
to arbitrarily favor one treatment over the other.
DEPRECATE: Some may take the deprecation of COERCE as an
aesthetic improvement because it eliminates the need to
debate this issue further. Others may see the
``de-centralization'' of coercion as a step backward.
Discussion:
Pitman supports COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION.
Hopefully Moon and Masinter support it, too, since it's
basically patterned after a bunch of mail they were sending
back and forth.
A proposal to extend COERCE to permit a ``view type'' argument
was considered and rejected as too extreme to consider seriously
in the timeframe available.
Pierson suggests that COERCE ought to be a candidate for
generic function status.
Pitman thinks that making [two-argument] COERCE generic would
be a -very- bad idea but believes that his earlier proposal
involving a third `view type' argument might be able to
accomodate such extension.
∂07-Mar-89 1504 CL-Cleanup-mailer MERGE-PATHNAMES-DIRECTORY:EXTEND
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 89 15:03:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 552503; Tue 7-Mar-89 18:01:39 EST
Date: Tue, 7 Mar 89 18:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: MERGE-PATHNAMES-DIRECTORY:EXTEND
To: Aaron Larson <alarson@src.honeywell.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903041918.AA12921@pavo.src.honeywell.com>
Message-ID: <19890307230113.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
How does this relate to the existing issue PATHNAME-SUBDIRECTORY-LIST,
on which we have not yet voted?
∂07-Mar-89 1637 CL-Cleanup-mailer Issue: OPTIMIZE-SAFETY (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 89 16:35:10 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 552571; Tue 7-Mar-89 19:32:29 EST
Date: Tue, 7 Mar 89 19:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: OPTIMIZE-SAFETY (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, RPG@Lucid.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890306174235.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890308003210.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 6 Mar 89 17:42 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Sorry this is last-minute, but I believe it to be important.
Me too. But maybe it's already taken care of in the editorial
committee; see below. Also see an important question posed in
the last three paragraphs.
Problem Description:
CLtL permits implementations to ignore OPTIMIZE declarations,
yet the new error terminology has a term ``should signal''
which guarantees that certain errors will be signalled in highest
safety.
This situation is at odds with the desire on the part of some vendors
to provide highly delivery configurations for Common Lisp, which
are streamlined to be small and fast at the expense of error checking.
If an implementation is permitted to start out in low safety mode,
and is also permitted to ignore OPTIMIZE SAFETY declarations, then
the meaning of ``should signal'' is called into question.
Proposal (OPTIMIZE-SAFETY:START-SAFE-OR-HEED-OPTIMIZE):
1. Define the initial safety setting of an implementation's
OPTIMIZE declarations to be implementation dependent. Conforming
implementations must document the initial setting.
2. Require every implementation to do at least one (and possibly
both) of the following:
a. Start in highest safety mode.
b. Not ignore the OPTIMIZE declaration.
Put another way, an implementation implementation which starts
out in ``unsafe'' mode is prohibited from ignoring OPTIMIZE
declarations that would allow the programmer to declare code
to require ``safe'' treatment.
Item 1 is pretty non-controversial and is probably the status quo
of the current draft specification.
Item 2 appears to be a rewording of what the ERROR-TERMINOLOGY editorial
issue already says, unless I am missing something, in its definition of
the terms "safe code" and "unsafe code."
By the way, I'm pleased to note that the earlier idea that the
interpreter is always safe has been dropped, and there is now no
explicit distinction between the interpreter and the compiler. I assume
this means that an implementation must either treat all interpreted code
as safe, or respect OPTIMIZE declarations in the interpreter, or not
have an interpreter and compile everything.
Current Practice:
Symbolics Genera and Symbolics Cloe conform to the stated proposal.
I think this is true only in the trivial sense that the language those
two implementations implement, CLtL Common Lisp, does not have any
situations that are specified to signal an error in safe code. I
haven't reviewed the draft standard yet, but presumably when we are
finished there will be hundreds of situations specified to signal an
error in safe code, and only some fairly arbitrary subset of those
situations will signalled in the two Symbolics implementations, until
they are converted from implementing CLtL Common Lisp to implementing
the new Common Lisp. Currently Genera always runs in safe mode, but
that safe mode does not check the same conditions that the future Common
Lisp standard will presumably require to be checked.
I do have a question about the intended meaning of safe code. Is safe
code a development environment feature, in which case it makes sense for
there to be non-development-oriented implementations that do not provide
the feature. Is safe code something you turn on while developing new
programs that you don't trust, but only the programmer depends on, and
the functioning of a correct program never depends on an error being
signalled because the error occurs in safe code?
Or on the other hand is safe code a language feature that is going to be
used routinely in portions of delivered applications where the
programmer has deliberately chosen safe mode as a way of implementing
control structure of the program?
Kent's proposal here, and the ERROR-TERMINOLOGY editorial proposal, seem
to incline towards the language feature, but it's certainly an odd
way to implement control structure.
∂07-Mar-89 1643 CL-Cleanup-mailer Issue: BREAK-ON-WARNINGS-OBSOLETE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 89 16:43:45 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 552576; Tue 7-Mar-89 19:41:27 EST
Date: Tue, 7 Mar 89 19:41 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: BREAK-ON-WARNINGS-OBSOLETE
To: CL-Cleanup@SAIL.Stanford.EDU
cc: chapman%aitg.dec@decwrl.dec.com
Message-ID: <890307194121.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
This issue came up in my review of the errors chapter for Kathy.
-kmp
-----
Issue: BREAK-ON-WARNINGS-OBSOLETE
Forum: Cleanup
References: *BREAK-ON-WARNINGS* (CLtL p432, CL Condition System p40)
*BREAK-ON-SIGNALS* (CL Condition System p25)
Category: CLARIFICATION/CHANGE
Edit history: 07-Mar-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
With the advent of *BREAK-ON-SIGNALS*, *BREAK-ON-WARNINGS* is
redundant and unnecessary.
Proposal (BREAK-ON-WARNINGS-OBSOLETE:DEPRECATE):
Deprecate *BREAK-ON-WARNINGS*.
Test Case:
N/A
Rationale:
This will lead to simplification of the description of WARN.
Not only are the two variables overkill, but they have an effect
in an identifiably but uselessly distinct place.
Current Practice:
Since deprecation is not removal, presumably everyone who conforms
is compatible.
Cost to Implementors:
Since the feature is deprecated rather than flushed: none.
Cost to Users:
Since the feature is deprecated rather than flushed: none.
Users should get used to writing (SETQ *BREAK-ON-SIGNALS* 'WARNING)
rather than (SETQ *BREAK-ON-WARNINGS* T).
Cost of Non-Adoption:
The definition of WARN will be gratuitously cluttered.
Benefits:
Cost of non-adoption is avoided.
Aesthetics:
Slight improvement.
Discussion:
Pitman thinks this is a good idea, but doesn't think a lot of time
should be wasted discussing the issue if there is strong opposition.
∂07-Mar-89 1722 CL-Cleanup-mailer Issue EQUALP-GENERIC
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 89 17:22:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 552600; Tue 7-Mar-89 20:20:21 EST
Date: Tue, 7 Mar 89 20:20 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue EQUALP-GENERIC
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU, JonL@LUCID.COM
In-Reply-To: <12474360416.19.IIM@ECLA.USC.EDU>
Message-ID: <19890308012006.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think you did some good work here, but I don't think you solved
all the problems that Gregor and I discovered in our walk on the beach.
If I were you, I would give up and not try to solve the problem of
making EQUALP generic within the Common Lisp standard (I might still
try to solve it as a research effort). Details below. Sorry about
the length.
On the related question of "what did CLtL mean by the undefined
phrase `objects that have components'," I would prefer to abide by
the Kauai decision that this doesn't include structures and instances
of defclass-defined classes, rather than discuss the issue endlessly.
On the other hand, I wouldn't shout down anyone who took the trouble
to write up a cleanup issue in standard form.
Date: Tue 28 Feb 89 13:48:20-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
In response to JonL's complaint that a proposal to make EQUALP a generic
function did not seem to be forthcoming ...
-----
Forum: Cleanup
Issue: EQUALP-GENERIC
References: EQUALP, p81
Related issues: EQUAL-STRUCTURE
HASH-TABLE-STABILITY
HASH-TABLE-TESTS
Category: CHANGE ADDITION
Edit history: Version 1, 02-28-89, Kim A. Barrett
Problem description:
The recent acceptance of Issue EQUAL-STRUCTURE (as ammended) has generated
some complaints about its specified behavior on objects with metaclass
STRUCTURE-CLASS. Some programs which depend on EQUALP comparing the
components of structures are now broken.
There are some who feel that EQUALP could be made much more useful than it
currently is by making it user extensible, but there are potential
difficulties due to the recent acceptance of Issue HASH-TABLE-TESTS, which
added EQUALP as a valid hash-table test.
Proposal (EQUALP-GENERIC:YES):
Specify that EQUALP is a generic function, and define the new generic function
EQUALP-HASH. Specify that a necessary requirement on all methods for these
functions is that (EQUALP x y) => (= (EQUALP-HASH x t) (EQUALP-HASH y t)).
Add a discussion of the constraints on equivelence predicates and their
corresponding hash functions, similar to that presented in Issue
HASH-TABLE-STABILITY.
OK so far.
CLtL says that objects that have components are only EQUALP if the two objects
are of the same type. Perhaps this vague phrase means that CLASS-OF returns
the same (EQ) class for both of them. Who enforces this? And who enforces
that numbers are an exception to this rule? Does every method enforce this,
or is there some kind of shared code?
EQUALP object1 object2 [Generic Function]
The generic function EQUALP is a predicate which can be called to compare two
objects for equivelence. The precise definition of equivelence is specified
by the methods defined on this function. The result is either true or false,
depending on whether the objects are equivelent.
Method Signatures:
EQUALP (object1 NUMBER) (object2 NUMBER) [Primary Method]
Defines equality as being =.
EQUALP (object1 CHARACTER) (object2 CHARACTER) [Primary Method]
Defines equality as being CHAR-EQUAL.
EQUALP (object1 CONS) (object2 CONS) [Primary Method]
Defines equality as having EQUALP CAR's and EQUALP CDR's.
EQUALP (object1 PATHNAME) (object2 PATHNAME) [Primary Method]
Defines equality as being EQUAL.
EQUALP (object1 VECTOR) (object2 VECTOR) [Primary Method]
Defines equality as having the same length (observing fill-pointers when
present), and every pair of corresponding components are EQUALP.
EQUALP (object1 ARRAY) (object2 ARRAY) [Primary Method]
Defines equality as having the same rank and dimensions, and every pair of
corresponding components are EQUALP.
EQUALP (object1 HASH-TABLE) (object2 HASH-TABLE) [Primary Method]
Defines equality as satisfying the following conditions:
1. Each hash-table uses the same test function.
2. Each hash-table contains entries for the same set of keys, where the test
function is used to determine the equivelence of keys.
3. For each key, the associated values from the two tables are EQUALP.
EQUALP (object1 T) (object2 T) [Primary Method]
The default method defines equality as being EQ.
Remarks:
An error is signaled on an attempt to add a method on any built-in class.
Adding a method on a class after ALLOCATE-INSTANCE has been called on the
class has undefined consequences. Implementations may be extended in this
case.
An implementation may specify additional methods on this function.
EQUALP-HASH object &optional use-pointer depth [Generic Function]
The generic function EQUALP-HASH is a called to compute a hash code for the
Object. Use-Pointer is a flag. If true, the memory location of the object
may be used to generate the hash code. The default is false.
I couldn't figure out how use-pointer is to be used. Are we saying anything
about what value a hash table supplies for this argument? Up at the top you
seemed to imply that hash tables supply T. Then what use is the NIL value?
Depth is used to control the depth of recursion, allowing cuttoff. This
prevents infinite recursion in the case of circular references. Callers of
this function should not explicitely specify a value for this argument.
Methods on this function which need to make recursive calls should simply
pass the Depth argument along unchanged.
The depth thing is a new feature since CLtL p.81 says EQUALP is permitted
to be non-terminating if given circular arguments.
Perhaps we should leave our the optional arguments and keep things simple.
But that's not my main point, which is still to come.
This function returns two values. The first value is the hash code, which is
a non-negative fixnum. The second value is a flag indicating whether the
memory location of the object (or any component) was used in generating the
hash code. A caller who specifies NIL for the Use-Pointer argument may
reliably depend on the second value being false.
The second value is not well enough specified. The problem is that if
an equalp-hash method for an object with components works by calling
equalp-hash recursively on each component and combining the results,
it has to combine both values. Since you said the first value is
a non-negative fixnum, we know it can be combined with LOGXOR or
something more intelligent. You haven't said anything about how to
combine the second value. You may be assuming that the second value
is T or NIL and the appropriate combining function is OR, but you
haven't said that. In fact a simple binary flag isn't really good
enough, because many implementations have multiple levels of memory
(volatility, ephemeralness, generations) and efficiency dictates that
the second value indicate which level was depended upon. Possibly
it would work to require the second value to be an integer and use
MAX as the combining function. Or perhaps there should be a specific
combining function for this purpose with an implementation-dependent
behavior. Even that isn't good enough, because a user who writes
an equalp-hash method that actually computes a hash code, without
recursing into components, has to know what to return as the second
value. We could say that NIL or 0 or some named constant means
the first value does not depend on any memory locations.
This function is used by the implementation to compute hash codes for EQUALP
hash-tables. By specifying a NIL value for the second argument, it may also
be used to compute a code which is independent of the particular
"incarnation" or "core image", just as for SXHASH.
Now wait a minute, I think being independent of the core image and being
independent of objects changing their address are two different issues.
There can be other things besides memory addresses that are dynamically
allocated on a per-core-image basis. Character codes in systems with
user-defined character registries are a classic example. You need to
clarify whether use-pointer NIL means the value cannot change within
the core image (e.g. when a relocating GC changes memory addresses)
or means the value cannot change within the implementation (e.g. when
you apply equalp-hash in a different core image to an object that is
considered to be equivalent).
Method Signatures:
EQUALP-HASH (object NUMBER) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object CHARACTER) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object CONS) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object PATHNAME) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object VECTOR) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object ARRAY) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object HASH-TABLE) &optional use-pointer depth [Primary Method]
EQUALP-HASH (object T) &optional use-pointer depth [Primary Method]
The manner in which the hash code is computed by the standard methods on
this function is implementation dependent.
It's pretty unclear what the EQUALP-HASH method on T would do with a
second argument of NIL. What else can it use but the pointer (and
perhaps the class)? I don't see what it can do but return a constant
value for all objects. Maybe it would be better off signalling an
error. Or maybe this is another argument against the use-pointer
feature.
∂07-Mar-89 1825 CL-Compiler-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 89 18:24:55 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 552620; Tue 7-Mar-89 21:21:40 EST
Date: Tue, 7 Mar 89 21:21 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Potential issue: MACRO-SPECIAL-FORMS
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, cl-compiler@sail.stanford.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: <3256.8902271723@subnode.aiai.ed.ac.uk>
Message-ID: <19890308022127.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Just a comment: I really believe that CLtL's goal of minimizing the
number of special forms that a code-analyzer has to understand by
relying on macros is misguided and non-achievable. Consider Sandra's
experience, which I believe other people have had in other
implementations, with something that CLtL says is a macro, but the
compiler does a better job of compiling the macro call than of compiling
the nominally equivalent macro expansion. Just consider how well CLtL's
goal has been achieved in practice: not at all.
I think Common Lisp would do better to define everything that "everybody
knows" is a special form to be a special form; this would include all
the control structures, but not SETF. My claim is that this would not
make it any more difficult to do code analysis, because in practice code
analyzers have to know about most of those forms anyway, and because the
extra work to make a typical code analyzer know about a typical special
form, even something as complicated as DO, is usually fairly small,
certainly less work than figuring out what weird macro expansions all
the implementations in the world will use for DO and making sure the
code analyzer works right for each of them. This is even more true when
you use a pattern-driven code analyzer, such as the one I wrote in 1983
and have given to everyone who asked, or the one in Interlisp
MasterScope (which was my model, although I didn't look at the detailed
code).
An alternative position that I'd consider would be to mandate the exact
macro expansion of a number of these forms, not allowing implementations
to deviate. Essentially that would be moving these things into a
portable library. I suppose that might devolve into endles nitpicking
discussions that we don't need.
∂07-Mar-89 2346 CL-Cleanup-mailer MERGE-PATHNAMES-DIRECTORY:EXTEND
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 7 Mar 89 23:45:57 PST
Return-Path: <alarson@src.honeywell.com>
Received: from quasar.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Tue, 7 Mar 89 21:17:29 CST id AA25303 for cl-cleanup@sail.stanford.edu
Posted-Date: Tue, 7 Mar 89 21:16:34 CST
Received: by quasar.src.honeywell.com (3.2/SMI-3.2)
id AA05965; Tue, 7 Mar 89 21:16:34 CST
Date: Tue, 7 Mar 89 21:16:34 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903080316.AA05965@quasar.src.honeywell.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 7 Mar 89 18:01 EST <19890307230113.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: MERGE-PATHNAMES-DIRECTORY:EXTEND
Posted-Date: Tue, 7 Mar 89 18:01 EST
Date: Tue, 7 Mar 89 18:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
How does this relate to the existing issue PATHNAME-SUBDIRECTORY-LIST,
on which we have not yet voted?
I'm not sure, I've never seen the PATHNAME-SUBDIRECTORY-LIST proposal. I
had been talking to cperdue and pitman about pathname cleanup issues (I'm
not currently on the cleanup list). They both alluded to the fact that
there was a pathname cleanup similar to the one I was writing, but I never
got a copy of it, and the last time I checked there wasn't a copy in the
cl-cleanup/pending directory on arisia.
If it would reduce confusion, I'm willing to be put on the cleanup list, or
if I could get a copy of the PATHNAME-SUBDIRECTORY-LIST proposal, I could
either summarize the diffs, or retract mine.
Sorry for any confusion.
∂08-Mar-89 0524 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 8 Mar 89 05:24:11 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA27319; Wed, 8 Mar 89 05:22:15 PST
Message-Id: <8903081322.AA27319@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for cl-cleanup@sail.stanford.edu; id AA27319; Wed, 8 Mar 89 05:22:15 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 8 Mar 89 08:22
To: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: COPY-SYMBOL-PRINT-NAME
Issue: COPY-SYMBOL-PRINT-NAME
References: COPY-SYMBOL (p. 169)
Category: CLARIFICATION
Edit history: 1-MAR-89, Version 1 by Chapman
Problem Description:
The description of COPY-SYMBOL states that it "returns a new uninterned
symbol with the same print name as sym (its first argument)". The words
"the same as" are not defined in CLtL. Do they mean EQ, EQUAL, ...?
Proposal (COPY-SYMBOL-PRINT-NAME:EQUAL)
The description of COPY-SYMBOL should read as follows:
"COPY-SYMBOL returns an uninterned
symbol whose print name is EQUAL to
the print name of the symbol that is the first argument to COPY-SYMBOL."
Rationale:
This clarification resolves any possibility of ambiguity.
Current Practice:
?
Adoption Cost:
?
Benefits:
Less ambiguity in the specification, and potentially more portable code.
Conversion Cost:
?
Aesthetics:
None.
Discussion:
∂08-Mar-89 0806 CL-Cleanup-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 8 Mar 89 08:06:31 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab09969; 8 Mar 89 9:16 EST
Received: from draper.com by RELAY.CS.NET id ab28425; 8 Mar 89 9:10 EST
Date: Wed, 8 Mar 89 08:02 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Potential issue: MACRO-SPECIAL-FORMS
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
I'd agree with turning macros back into special forms provided that CL
defines a code-walker as part of the language. Such a code-walker should
accept functions as user-provided arguments to do things to each evaluable
form, each occurrence of a variable, etc., etc. - in other words, all the
points at which interesting stuff is done by real code-walkers.
Proposal, anybody?
∂08-Mar-89 0820 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME
Received: from multimax.encore.com ([129.91.1.14]) by SAIL.Stanford.EDU with TCP; 8 Mar 89 08:20:45 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA25548; Wed, 8 Mar 89 11:12:48 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA03566; Wed, 8 Mar 89 11:10:29 EST
Message-Id: <8903081610.AA03566@mist.>
To: "chapman%aitg.DEC@decwrl.dec.com"@multimax.encore.com
Cc: cl-cleanup@sail.stanford.edu,
"skona%csilvax@hub.ucsb.edu"@multimax.encore.com
Subject: Re: Issue: COPY-SYMBOL-PRINT-NAME
In-Reply-To: Your message of 08 Mar 89 08:22:00 -0500.
<8903081322.AA27319@decwrl.dec.com>
Date: Wed, 08 Mar 89 11:10:27 EST
From: Dan L. Pierson <pierson@mist.encore.com>
The description of COPY-SYMBOL should read as follows:
"COPY-SYMBOL returns an uninterned
symbol whose print name is EQUAL to
the print name of the symbol that is the first argument to COPY-SYMBOL."
I think that the comparison function should be STRING=. It does return
the same result as EQUAL, but it's more precise since we know that
strings are the only things to be compared here.
∂08-Mar-89 0930 CL-Cleanup-mailer Issue: MERGE-PATHNAMES-DIRECTORY
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Mar 89 09:30:05 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 552901; Wed 8-Mar-89 12:27:21 EST
Date: Wed, 8 Mar 89 12:27 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MERGE-PATHNAMES-DIRECTORY
To: Aaron Larson <alarson@src.honeywell.com>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903080316.AA05965@quasar.src.honeywell.com>
Message-ID: <890308122712.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
I just now forwarded you a copy of PATHNAME-SUBDIRECTORY-LIST.
If possible, please suggest ammendments to it.
Otherwise, please say why it is sufficiently different that you
want an alternate proposal.
∂08-Mar-89 0939 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Mar 89 09:39:24 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 552911; Wed 8-Mar-89 12:37:07 EST
Date: Wed, 8 Mar 89 12:36 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: COPY-SYMBOL-PRINT-NAME
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903081610.AA03566@mist.>
Message-ID: <890308123658.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
I see no reason not to just say it returns a symbol whose name is EQ.
No one is supposed to ever side-effect such strings, so that's not
an issue.
Not saying the result is EQ just encourages paranoid implementors to
copy the string unnecesarily, leading to a loss of space for no good
reason.
∂08-Mar-89 0948 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Mar 89 09:48:10 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 552918; Wed 8-Mar-89 12:45:48 EST
Date: Wed, 8 Mar 89 12:45 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: COPY-SYMBOL-PRINT-NAME
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890308123658.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890308174529.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 8 Mar 89 12:36 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I see no reason not to just say it returns a symbol whose name is EQ.
There might be implementations that, like Multics Maclisp, have a special
representation for symbol names rather than using an actual string. This
could make it impossible for
(eq (symbol-name (copy-symbol x)) (symbol-name x))
to be true. I think string= is the correct predicate.
No one is supposed to ever side-effect such strings, so that's not
an issue.
Not saying the result is EQ just encourages paranoid implementors to
copy the string unnecesarily, leading to a loss of space for no good
reason.
While I agree that the string should not be copied unnecessarily, I think
there are legitimate implementation techniques that would copy the string
necessarily.
∂08-Mar-89 0951 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Mar 89 09:51:39 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA04638g; Wed, 8 Mar 89 09:44:46 PST
Received: by blacksox id AA01816g; Wed, 8 Mar 89 09:49:28 PST
Date: Wed, 8 Mar 89 09:49:28 PST
From: Eric Benson <eb@lucid.com>
Message-Id: <8903081749.AA01816@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 8 Mar 89 12:36 EST <890308123658.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-PRINT-NAME
It is suggested in CLtL that an implementation might copy symbol names
into a readonly area. There is a comment in the defintion of
MAKE-SYMBOL saying that (EQ S (SYMBOL-NAME (MAKE-SYMBOL S))) might be
false. I think this proposal just extends that allowance to
COPY-SYMBOL.
Personally, I've never seen a program that *used* COPY-SYMBOL.
∂08-Mar-89 0952 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Mar 89 09:52:33 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 552925; 8 Mar 89 12:50:14 EST
Date: Wed, 8 Mar 89 12:50 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: COPY-SYMBOL-PRINT-NAME
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19890308174529.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890308125005.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 8 Mar 89 12:45 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Wed, 8 Mar 89 12:36 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I see no reason not to just say it returns a symbol whose name is EQ.
There might be implementations that, like Multics Maclisp, have a special
representation for symbol names rather than using an actual string.
could make it impossible for
(eq (symbol-name (copy-symbol x)) (symbol-name x))
to be true. I think string= is the correct predicate.
Ok, given this explanation, STRING= is fine by me.
No one is supposed to ever side-effect such strings, so that's not
an issue.
Not saying the result is EQ just encourages paranoid implementors to
copy the string unnecesarily, leading to a loss of space for no good
reason.
While I agree that the string should not be copied unnecessarily, I think
there are legitimate implementation techniques that would copy the string
necessarily.
Maybe this can be factored in as an implementation note.
∂08-Mar-89 1117 CL-Cleanup-mailer Issue: PLUS-ABNORMAL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Mar 89 11:17:44 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 552995; Wed 8-Mar-89 14:14:38 EST
Date: Wed, 8 Mar 89 14:14 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PLUS-ABNORMAL
To: chapman%aitg.DEC@decwrl.dec.com
cc: CL-Cleanup@SAIL.Stanford.EDU, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8903081318.AA27193@decwrl.dec.com>
Message-ID: <890308141430.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Personally, I think it follows as a logical inductive consequence of the
description on p325 that this is already true. However, if someone
thinks it needs to be stated explicitly, that's fine.
The proposal is poorly worded in a few places because it talks about
the evaluation of + when it should refer to the evaluation of the
`input expression' or some such.
(The proposal is possibly incomplete in that if you're going to specify
this, you might also want to specify the same thing for the variable -.
Within a use of #. the variable - is usually bound to the same as + . :-)
I wonder if it's a good idea to be so specific about all this though.
There are other gray areas that we might want to specify as well, and
we may quickly end up infringing on `the environment.'
Other problems I've had with these variables are:
- Some implementations do not update * and company when the result
was generated by (VALUES).
Symbolics does this. It's in violation of CLtL, but I happen to
think that it's a good idea anyway since it can't break programs
and since it's what makes it really useful to have DESCRIBE and
PPRINT return that. Otherwise, they might as well return NIL.
I really think CL made a mistake on this one.
- Some debuggers do not maintain +, *, etc. while you're debugging,
while others do.
I think it's correct to make them available. When I used to use
Vaxlisp, they were not made available, for example.
- Some debuggers that make +, *, etc. available in the debugger
do so by binding. Others continue to SETQ the same variables.
I think continuing to SETQ the same variables is most useful,
because it means you can still get back to the values you made
in the debugger after you return. However, I think others
could legitimately disagree.
- Of the debuggers which make +, *, etc. available by binding, not
all initialize the values to the same values from the outer
context.
I happen to think that if you do it this way, the initial values
should be the values of the `outer' variables.
This list is probably not exhaustive.
If any of these issues were to be raised, I think they should be raised
within the bounds of this proposal and not in a separate one, to
minimize paperwork.
I kind of think that if we want to do anything with +, ++, etc. it may
be to say that they are reserved for the implementation to assign as it
sees fit, and to give only vague guidelines beyond that -- referring
people to the implementation's manual for specifics.
If further revisions of the proposal are submitted, the few occurrences
of {\tt ...} should be dropped as unnecessary.
∂08-Mar-89 1437 CL-Cleanup-mailer case sensitive readers
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 89 14:37:27 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
id AA02242; Wed, 8 Mar 89 14:24:29 -0800
Received: from frisky by franz (3.2/3.14)
id AA04190; Wed, 8 Mar 89 10:18:33 PST
Received: by frisky (3.2/3.14)
id AA07089; Wed, 8 Mar 89 10:18:07 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8903081818.AA07089@frisky>
To: franz!sail.stanford.edu!cl-cleanup
Subject: case sensitive readers
Date: Wed, 08 Mar 89 10:18:04 PST
Jeff Dalton brought up the problem of the Lisp reader not being case
sensitive. His application was to read text in which case matters.
I think that we would be better served in solving the global problem of
a solely case insensitive reader, and once this is solved Jeff's problem
disappears.
As a user of Lisp on Unix-based workstations the fact that Common Lisp
is not case-sensitive is a major annoyance. [While Allegro Common Lisp
will run in a case-sensitive mode, the fact that most of what I write
gets shipped to customers means that I have to limit my use of
case-sensitivity]. Clearly many people find case-sensitivity a useful
tool for increasing program readability (if you don't believe this, look at
large C programs and remind yourself that C doesn't impose any
case conventions on the user so that all use of case is strictly
voluntary). Furthermore many people use Lisp on Unix-based workstations
to interface with C, and the fact that there isn't a nice way to
write dual-cased C symbols as Lisp symbols is a major drawback to
seamless integration.
If you now want to reply to this letter letting me know how much you hate
case-sensitive programming languages, please don't bother. It just
doesn't matter what you dislike. What matters is that there
do exist a significant number people for whom the case-sensitivity
is important (unfortunately they are probably under-represented in this forum).
It is possible to come up with a solution that also satisfies people
who are used to using case freely in their programs
(e.g. (Defun Foo (x) (Cond (X :BaR))))
and who want all characters mapped to one case. This is done by
some mechanism that lets the reader know when it should map all
unescaped characters to one case.
Furthermore I'd expect that all symbols defined in the standard be
of a single case so that people using Lisp in the single-case mode
would have access to everything without using escape characters.
Now for the big change: If Common Lisp is to support a case-sensitive
reader for programs, the 'standard' case for symbol names must be
lower case. This is very important because having to use the
shift key to type in most symbol names would make the
case-sensitive mode too painful to be useful.
Allegro Common Lisp can switch at runtime between the standard
Common Lisp case-insensitive upper-case-preferred mode and
the case-sensitive lower-case-preferred mode I've suggested here,
however this is a 'violent' change that isn't necessarily reverseable
and I wouldn't suggest this kind of thing for the standard.
It is trivial to switch between the case-insensitive lower-case-preferred and
case-sensitive lower-case-preferred modes and these are the two modes
I'd suggest be supported in Common Lisp. I don't care how the switch is done
(whether by global variable, readtable-based flag, or function). I believe
that the first step is deciding that the mode switch is necessary and
then the design can be done.
- john foderaro
Franz Inc.
∂08-Mar-89 1628 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Mar 89 16:27:10 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 MAR 89 16:13:38 PST
Date: 8 Mar 89 16:13 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: COPY-SYMBOL-PRINT-NAME
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 8 Mar 89 12:45 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890308-161338-10981@Xerox>
Medley did this: the symbol names didn't really have a string header and
some symbol names (the "initial symbols" ) had a different place for
storing the actual characters than symbols created later. Unfortunately,
that means that SYMBOL-NAME has to CONS.
It wasn't so much a problem for Interlisp since most of the "string"
functions in Interlisp will take symbols, but in Common Lisp, it is a
performance hit. Poor design, but there's no reason to require SYMBOL-NAME
to return EQ strings.
In this case, the strings aren't EQ even though the string characters are
shared. (Think of it as strings displaced to a shared area.)
∂09-Mar-89 1109 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 11:09:10 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 553826; Thu 9-Mar-89 14:06:34 EST
Date: Thu, 9 Mar 89 14:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOS-CONDITIONS (Version 3)
To: masinter.pa@Xerox.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890203-223055-2803@Xerox>
Message-ID: <19890309190624.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I favor CLOS-CONDITIONS:YES-OPTION-B, even though it's more
verbose, because it makes for a more consistent language.
I don't think the compatibility issue is important since we're
only talking about being compatible with a prototype that some
people have used, not being compatible with a widely used
standard. Essentially, I agree with JonL's comment of 9 Feb.
Would it make sense to offer only YES-OPTION-B to the whole
X3J13 committee, in order to limit the length of the discussion?
Or is that excessively Fascist?
∂09-Mar-89 1120 CL-Cleanup-mailer Re: case sensitive readers
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Mar 89 11:19:14 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09234; 9 Mar 89 18:22 GMT
Date: Thu, 9 Mar 89 18:51:47 GMT
Message-Id: <29883.8903091851@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: case sensitive readers
To: John Foderaro <@NSS.Cs.Ucl.AC.UK,@aiai.edinburgh.ac.uk,@ucbarpa.berkeley.edu,@franz.uucp:jkf@frisky>,
cl-cleanup@sail.stanford.edu
In-Reply-To: John Foderaro's message of Wed, 08 Mar 89 10:18:04 PST
> Jeff Dalton brought up the problem of the Lisp reader not being case
> sensitive. His application was to read text in which case matters.
> I think that we would be better served in solving the global problem of
> a solely case insensitive reader, and once this is solved Jeff's problem
> disappears.
Actually, I was proposing a way to get a switchable, case-sensitive
reader. I mentioned it's use for code and for reading list-structure
data.
However, I thought it will be very difficult to change the internal
case of Common Lisp to be lower case, so I didn't try to do that. I'd
prefer lower case, I think it has been shown that lower case is easier
to read, I would find lower case easier to use, and I think it really
will be too late to change after we have a standard. But I'm sure
many will argue that it's already too late now, and since I think
case-sensitivity has some value on its own, I didn't want to combine
it with something more controversial.
> As a user of Lisp on Unix-based workstations the fact that Common Lisp
> is not case-sensitive is a major annoyance.
I think it's worth pointing out that this isn't just a Unix issue.
Lower case has been used on other systems as well.
And in general Lisp seems to be moving towards lower case. Most
textbooks seems to use lower case these days, and I've seen code
(such as the T sources) that's lower case now when it used to be
upper.
∂09-Mar-89 1128 CL-Cleanup-mailer Re: Issue: CLOS-CONDITIONS (Version 3)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 9 Mar 89 11:23:31 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA04368; Thu, 9 Mar 89 14:21:59 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA00548; Thu, 9 Mar 89 14:19:30 EST
Message-Id: <8903091919.AA00548@mist.>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: CLOS-CONDITIONS (Version 3)
In-Reply-To: Your message of Thu, 09 Mar 89 14:06:00 -0500.
<19890309190624.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 09 Mar 89 14:19:28 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I favor CLOS-CONDITIONS:YES-OPTION-B, even though it's more
verbose, because it makes for a more consistent language.
I don't think the compatibility issue is important since we're
only talking about being compatible with a prototype that some
people have used, not being compatible with a widely used
standard. Essentially, I agree with JonL's comment of 9 Feb.
Even though I personally prefer the aesthetics of YES-OPTION-A, JonL
and Gregor have made a very strong case for YES-OPTION-B so I now
support it instead.
Would it make sense to offer only YES-OPTION-B to the whole
X3J13 committee, in order to limit the length of the discussion?
Or is that excessively Fascist?
The comments I got from non-cleanup members at Kuaui were that cleanup
should be making more decisions and giving more guidance. Some even
went to far as to say we had done a poor job because we didn't have an
explicit recomendation from cleanup attached to every issue.
Let's just present YES-OPTION-B and concentrate on dealing with more
difficult objections such as Thom Linden's (the policy of
CLOSification must be decided in general before voting in any piece of
it).
∂09-Mar-89 1128 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 11:28:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 553848; Thu 9-Mar-89 14:25:51 EST
Date: Thu, 9 Mar 89 14:25 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890215150320.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890309192541.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Feb 89 15:03 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Here's some questions/comments that need to be factored into the
next draft on this issue...
I don't have any record of anyone ever answering this message.
I reckoned that if someone answered it you might be more motivated
to come up with this next draft.
1. Moon has suggested that COPY-CONDITION is not necessary. Does anyone
disagree? I am willing to remove it, but doing so will make this
proposal less `compatible.' I don't care much one way or the other, but
I don't want to be accused of being `callous' toward people who do care.
If this committee will back me up on the removal of that function and
the resulting compatibility problems that could in principle (though
perhaps not in practice) come up, then I'll make the change. Opinions?
I still believe COPY-CONDITION is not necessary.
2. Moon has also asked that the syntax to SIGNAL-WITH-RESTARTS and
ERROR-WITH-RESTARTS be:
SIGNAL-WITH-RESTARTS signal-argument-list &rest restart-clauses
ERROR-WITH-RESTARTS signal-argument-list &rest restart-clauses
so that you would write
(SIGNAL-WITH-RESTARTS ('FOOD-COLOR-ERROR :FOOD 'LETTUCE :COLOR 'PINK)
...restart clauses...)
rather than
(SIGNAL-WITH-RESTARTS (MAKE-CONDITION 'FOOD-COLOR-ERROR
:FOOD 'LETTUCE :COLOR 'PINK)
...restart clauses...)
If you wanted to use MAKE-CONDITION, you would then write:
(SIGNAL-WITH-RESTARTS ((MAKE-CONDITION 'FOOD-COLOR-ERROR
:FOOD 'LETTUCE :COLOR 'PINK))
...restart clauses...)
The advantage of what he proposes is that you could write
(SIGNAL-WITH-RESTARTS ("Bad ~S color" 'FOOD)
...restart clauses...)
and a condition object would be created implicitly as with SIGNAL. A
possible disadvantage is that
(SIGNAL-WITH-RESTARTS (FOO BAR BAZ)
...restart clauses...)
might look to someone like the FOO in (FOO BAR BAZ) named a function
rather than a variable. Does anyone else have an opinion on this?
I still believe my suggestion would be an improvement, but I think
even better would be
(WITH-CONDITION-RESTARTS signal-form &rest restart-clauses)
where signal-form must be an invocation of SIGNAL, ERROR, WARN, or
perhaps a few others, or a macro that expands into such an invocation.
WITH-CONDITION-RESTARTS must signal an error at all levels of safety if
it does not recognize the signal-form. This is "weird" because it uses
a form for something other than evaluation (but not unprecedented; this
is exactly what SETF does). The advantage is that it just nests with an
existing syntax instead of inventing a new, awkward syntax.
Note that I stole the "good name" WITH-CONDITION-RESTARTS for this
commonly used syntax. The less commonly used primitive that just sets
up the restarts without signalling doesn't need as good a name.
3. Rees has suggested that the syntax for WITH-CONDITION-RESTARTS should be
WITH-CONDITION-RESTARTS condition-form restarts-form &BODY forms
rather than
WITH-CONDITION-RESTARTS (condition-form restarts-form) &BODY forms
which it is now. Does anyone else have an opinion?
This is probably a good idea. I'd probably name this one
WITH-CONDITION-RESTARTS-INTERNAL. But are we sure that this operation
needs to be named in the standard at all?
4. Rees has asked for advice about how the condition/restart association
might be implemented -- is some kind of alist structure held by a
special variable what was intended, or ought the condition have a
restarts slot. He and I talked a little about this and eventually he
agreed that it's pretty obvious that the relation should be externally
represented. It's important that the association not be done by a slot
in the condition because if you carry around the condition object after
you're done signalling, you don't want it to contain useless and/or
misleading information about restarts that no longer exist. I'll probably
add some notes to this effect when I generate the next draft.
This doesn't really require comment, unless someone seriously disagrees.
Agreed.
∂09-Mar-89 1135 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 11:35:25 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 553862; Thu 9-Mar-89 14:33:05 EST
Date: Thu, 9 Mar 89 14:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890307174023.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890309193255.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree that this is ready to send out. The thing about
COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION that strikes fear
into my heart is that it wipes out CLtL's simple statement that
any sequence type may be converted to any other sequence type,
and starts people asking questions like does
(coerce nil '(vector character)) => "" or "NIL"?
This concern is not reflected at all in the writeup.
I agree that this is ready to send out but I'm inclined to vote
no on both proposals and keep the (unsatisfactory) status quo.
∂09-Mar-89 1228 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 12:28:40 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 553963; Thu 9-Mar-89 15:23:35 EST
Date: Thu, 9 Mar 89 15:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
To: Patrick Dussud <dussud@lucid.com>, Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
Richard P. Gabriel <rpg@lucid.com>, masinter.pa@Xerox.COM, gls@Think.COM,
Jon L White <jonl@lucid.com>, Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8901271629.AA21144@challenger>,
<19890128032256.5.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<890130110045.5.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<8901301613.AA03528@challenger>,
<19890130164936.0.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<8901301750.AA03759@challenger>,
<890130142828.2.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<8901301933.AA03928@challenger>,
<8901302154.AA04106@challenger>,
<890130173552.5.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<890130-144905-6017@Xerox>,
<19890131045316.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<8902020519.AA03069@sauron.think.com>,
<8902061636.AA27928@verdi.think.com>,
<8902072038.AA23870@bhopal>,
<890214-155752-10883@Xerox>,
<890215094330.2.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<8902151603.AA03972@challenger>,
<890215-082818-12355@Xerox>,
<4398.8902151741@subnode.aiai.ed.ac.uk>,
<890215-111623-12827@Xerox>,
<890215142157.9.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<8902281036.AA08748@bhopal>,
<8902281913.AA03555@verdi.think.com>
Message-ID: <19890309202310.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
After re-reading all 24 of these messages, I believe that version 7,
mailed by KMP on Feb 15, adequately captures the result of the discussion.
I would certainly like to vote yes on it at the end of this month
and then never hear about it again. There are a couple of small
changes that are worth making; see below.
I believe it captures what RPG was looking for, but I'd like to hear
confirmation of that from Dick.
Part of this issue is JonL's concern that the type SIMPLE-ARRAY is not
adequately specified. I believe that the logical implications of the
version 7 proposal adequately specify the meaning of SIMPLE-ARRAY, and
that this is not a change from CLtL, only a clarification. Evidently
there are other ways to read the sentence at the bottom of p.28, but the
way I read it, it says that simple arrays are ones that an
implementation can handle in a more efficient manner, and that arrays
that don't use certain features are simple, but does not say that no
other arrays can be simple. Do we need to add any language to the
version 7 proposal to clarify this? Adding JonL's suggested
"This proposal does not alter the definition of SIMPLE-ARRAY in any way."
would be fine with me. By the way I feel that I completely understand
the stock hardware implementors' concern with simple arrays and that
this proposal does not harm that concern in any fashion.
The front of the version 7 writeup says Category: CLARIFICATION/CHANGE,
but I believe it is only a clarification. The only part that might be
counted as a change is the replacement of CLtL's "It is not permitted to
call ADJUST-ARRAY on an array that was not created with the :ADJUSTABLE
option" (p.297) with "ADJUST-ARRAY should signal an error if
ADJUSTABLE-ARRAY-P of its first argument is false." I think it's not a
change, because it doesn't affect any conforming programs, it only
affects implementations. As the proposal says
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Thus I would like to see the category at the front changed to plain
CLARIFICATION.
∂09-Mar-89 1313 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:13:35 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA06442g; Thu, 9 Mar 89 13:03:35 PST
Received: by challenger id AA01857g; Thu, 9 Mar 89 12:58:59 PST
Date: Thu, 9 Mar 89 12:58:59 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903092058.AA01857@challenger>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: dussud@lucid.com, KMP@STONY-BROOK.SCRC.Symbolics.COM,
masinter.pa@Xerox.COM, gls@Think.COM, jonl@lucid.com,
jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 9 Mar 89 15:23 EST <19890309202310.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
I agree with ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7) as written by
KMP. I agree with Moon that it is a clarification not a change.
-rpg-
∂09-Mar-89 1325 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:25:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554041; Thu 9-Mar-89 16:22:52 EST
Date: Thu, 9 Mar 89 16:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 2)
To: John Rose <jrose@Sun.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU,
CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: <8901140458.AA18401@lukasiewicz.sun.com>
Message-ID: <19890309212238.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 13 Jan 89 20:58:49 PST
From: jrose@Sun.COM (John Rose)
...
The creation form for an object is always evaluated before the
initialization form for that object. When either the creation form or
the initialization form references other objects of user-defined types
that have not been referenced earlier in the COMPILE-FILE, the
compiler collects all of the creation forms together and collects all
of the initialization forms together. All of the creation forms are
evaluated before any of the initialization forms. The order of
evaluation of the creation forms is unspecified except when the
ordering is forced by data dependencies. The order of evaluation of
the initialization forms is unspecified.
...
Why does the proposal restrict the evaluation initialization forms to
such a late time? Data dependencies would allow an object X's
initialization form to be executed any time after X's creation form had
finished.
Actually, it would be better (and no more difficult, it seems to me) to
be strict in the other direction: Objects should be initialized as early
as possible, and hence at a deterministic time. This would allow nodes
in non-circular structures to be built out of fully initialized subparts,
which is clearly something an application could need.
Good point. I've modified the proposal accordingly, although I did not use
your exact wording. Of course the time is not fully determinstic, but
it's more deterministic than in version 2 of the proposal.
∂09-Mar-89 1329 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:29:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554052; Thu 9-Mar-89 16:26:35 EST
Date: Thu, 9 Mar 89 16:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 3)
To: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
Message-ID: <19890309212623.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
At Kauai I was asked to keep working on this and come up with a modified
version based on comments received. Here it is. I hope this is ready
for voting so we can clear it out of the way.
Issue: LOAD-OBJECTS
References: none
Related issues: LOAD-TIME-EVAL,
CONSTANT-COMPILABLE-TYPES,
CONSTANT-CIRCULAR-COMPILATION
Category: ADDITION
Forum: Cleanup
Edit history: Version 1, 2-Jan-89, by Moon (for discussion)
Version 2, 13-Jan-89, by Moon (draft updated from discussion)
Version 3, 9-Mar-89, by Moon (changes suggested by discussion)
Problem description:
Common Lisp doesn't provide any way to use an object of a user-defined
type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program
compiled with COMPILE-FILE. The problem is that LOAD has to be able
to "reconstruct" an equivalent object when the compiled-code file is
loaded, but the programmer has no way to tell LOAD how to do that.
Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM):
Define a new generic function named MAKE-LOAD-FORM, which takes one
argument and returns two values. The argument is an object that is
referenced as a constant or as a self-evaluating form in a file being
compiled by COMPILE-FILE. The objective is to enable LOAD to
construct an equivalent object.
The first value, called the "creation form," is a form that, when
evaluated at load time, should return an object that is equivalent to
the argument. The exact meaning of "equivalent" depends on the type
of object and is up to the programmer who defines a method for
MAKE-LOAD-FORM. This is the same type of equivalence discussed
in issue CONSTANT-COMPILABLE-TYPES.
The second value, called the "initialization form," is a form that,
when evaluated at load time, should perform further initialization of
the object. The value returned by the initialization form is ignored.
If the MAKE-LOAD-FORM method returns only one value, the
initialization form is NIL, which has no effect. If the object used
as the argument to MAKE-LOAD-FORM appears as a constant in the
initialization form, at load time it will be replaced by the
equivalent object constructed by the creation form; this is how the
further initialization gains access to the object.
Both the creation form and the initialization form can contain
references to objects of user-defined types (defined precisely below).
However, there must not be any circular dependencies in creation forms.
An example of a circular dependency is when the creation form for the
object X contains a reference to the object Y, and the creation form
for the object Y contains a reference to the object X. A simpler
example would be when the creation form for the object X contains
a reference to X itself. Initialization forms are not subject to
any restriction against circular dependencies, which is the entire
reason that initialization forms exist. See the example of circular
data structures below.
The creation form for an object is always evaluated before the
initialization form for that object. When either the creation form or
the initialization form references other objects of user-defined types
that have not been referenced earlier in the COMPILE-FILE, the
compiler collects all of the creation and initialization forms. Each
initialization form is evaluated as soon as possible after its
creation form, as determined by data flow. If the initialization form
for an object does not reference any other objects of user-defined
types that have not been referenced earlier in the COMPILE-FILE, the
initialization form is evaluated immediately after the creation form.
If a creation or initialization form F references other objects of
user-defined types that have not been referenced earlier in the
COMPILE-FILE, the creation forms for those other objects are evaluated
before F, and the initialization forms for those other objects are
also evaluated before F whenever they do not depend on the object
created or initialized by F. Where the above rules do not uniquely
determine an order of evaluation, which of the possible orders of
evaluation is chosen is unspecified.
While these creation and initialization forms are being evaluated, the
objects are possibly in an uninitialized state, analogous to the state
of an object between the time it has been created by ALLOCATE-INSTANCE
and it has been processed fully by INITIALIZE-INSTANCE. Programmers
writing methods for MAKE-LOAD-FORM must take care in manipulating
objects not to depend on slots that have not yet been initialized.
It is unspecified whether LOAD calls EVAL on the forms or does some
other operation that has an equivalent effect. For example, the
forms might be translated into different but equivalent forms and
then evaluated, they might be compiled and the resulting functions
called by LOAD, or they might be interpreted by a special-purpose
interpreter different from EVAL. All that is required is that the
effect be equivalent to evaluating the forms.
COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
a constant or as a self-evaluating form, if the object's metaclass is
STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
subclass of BUILT-IN-CLASS), or any of a possibly-empty
implementation-defined list of other metaclasses. COMPILE-FILE will
only call MAKE-LOAD-FORM once for any given object (compared with EQ)
within a single file.
It is valid for user programs to call MAKE-LOAD-FORM in other
circumstances, providing the argument's metaclass is not BUILT-IN-CLASS
or a subclass of BUILT-IN-CLASS.
Define a new function named MAKE-LOAD-FORM-USING-SLOTS, which takes
one required argument and one optional argument and returns two
values. This can be useful in user-written MAKE-LOAD-FORM methods.
The first argument is the object. The optional second argument is a
list of the names of the slots to preserve; it defaults to all of the
local slots. MAKE-LOAD-FORM-USING-SLOTS returns forms that construct
an equivalent object using MAKE-INSTANCE and SETF of SLOT-VALUE for
slots with values, or SLOT-MAKUNBOUND for slots without values, or
using other functions of equivalent effect.
MAKE-LOAD-FORM-USING-SLOTS returns two values, thus it can deal with
circular structures. MAKE-LOAD-FORM-USING-SLOTS works for any object
of metaclass STANDARD-CLASS or STRUCTURE-CLASS. Whether the result is
useful in an application depends on whether the object's type and slot
contents fully capture the application's idea of the object's state.
MAKE-LOAD-FORM of an object of metaclass STANDARD-CLASS or
STRUCTURE-CLASS for which no user-defined method is applicable signals
an error. It is valid to implement this either by defining default
methods on STANDARD-OBJECT and STRUCTURE-OBJECT that signal an error
or by having no applicable method for those classes.
Examples:
;; Example 1
(defclass my-class ()
((a :initarg :a :reader my-a)
(b :initarg :b :reader my-b)
(c :accessor my-c)))
(defmethod shared-initialize ((self my-class) ignore &rest ignore)
(unless (slot-boundp self 'c)
(setf (my-c self) (some-computation (my-a self) (my-b self)))))
(defmethod make-load-form ((self my-class))
`(make-instance ',(class-name (class-of self))
:a ',(my-a self) :b ',(my-b self)))
In this example, an equivalent instance of my-class is reconstructed
by using the values of two of its slots. The value of the third slot
is derived from those two values.
Another way to write the last form in the above example would have been
(defmethod make-load-form ((self my-class))
(make-load-form-using-slots self '(a b)))
;; Example 2
(defclass my-frob ()
((name :initarg :name :reader my-name)))
(defmethod make-load-form ((self my-frob))
`(find-my-frob ',(my-name self) :if-does-not-exist :create))
In this example, instances of my-frob are "interned" in some way.
An equivalent instance is reconstructed by using the value of the
name slot as a key for searching existing objects. In this case
the programmer has chosen to create a new object if no existing
object is found; alternatively she could have chosen to signal an
error in that case.
;; Example 3
(defclass tree-with-parent () ((parent :accessor tree-parent)
(children :initarg :children)))
(defmethod make-load-form ((x tree-with-parent))
(values
;; creation form
`(make-instance ',(class-of x) :children ',(slot-value x 'children))
;; initialization form
`(setf (tree-parent ',x) ',(slot-value x 'parent))))
In this example, the data structure to be dumped is circular, because
each parent has a list of its children and each child has a reference
back to its parent. Suppose make-load-form is called on one object in
such a structure. The creation form creates an equivalent object and
fills in the children slot, which forces creation of equivalent
objects for all of its children, grandchildren, etc. At this point
none of the parent slots have been filled in. The initialization form
fills in the parent slot, which forces creation of an equivalent
object for the parent if it was not already created. Thus the entire
tree is recreated at load time. At compile time, MAKE-LOAD-FORM is
called once for each object in the true. All of the creation forms
are evaluated, in unspecified order, and then all of the
initialization forms are evaluated, also in unspecified order.
;; Example 4
(defstruct my-struct a b c)
(defmethod make-load-form ((s my-struct))
(make-load-form-using-slots s))
In this example, the data structure to be dumped has no special
properties and an equivalent structure can be reconstructed
simply by reconstructing the slots' contents.
Rationale:
Only the programmer who designed a class can know the correct
way to reconstruct objects of that class at load time, therefore
the reconstruction should be controlled by a generic function.
Using EVAL as the interface for telling LOAD what to do provides
full generality.
MAKE-LOAD-FORM returns two values so that circular structures can
be handled. If CONSTANT-CIRCULAR-COMPILATION is rejected,
MAKE-LOAD-FORM will only return one value, although implementations
that make an extension to support circular constants will probably
also make the extension to accept two values from MAKE-LOAD-FORM.
The default for class objects and structures is to signal an error,
rather than picking some particular object reconstruction technique,
because no reconstruction technique is appropriate for all objects.
It only takes two lines of code, as in example 4, to instruct the
compiler to use the technique that most often has been suggested
as the default.
MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT, as a hook
for the programmer to control the system's actions.
The order of evaluation rules for creation and initialization forms
eliminate the possibility of partially initialized objects in the
absence of circular structures, and reduce it to the minimum possible
in the presence of circular structures. This allows nodes in
non-circular structures to be built out of fully initialized subparts.
Current practice:
Symbolics Flavors has something like this, but under a different name.
The name Symbolics uses is not suitable for standardization.
JonL reports that Lucid is getting more and more requests for this.
Cost to Implementors:
This seems like only a few one-line changes in the compiled-code
file writer and reader. MAKE-LOAD-FORM-USING-SLOTS is a couple
dozen lines of code, assuming the presence of the CLOS metaobject
protocol or an implementation-dependent equivalent.
Cost to Users:
None.
Cost of non-adoption:
Serious impairment of the ability to use extended-type objects. Each
implementation will probably make up its own version of this as an
extension.
Performance impact:
None.
Benefits:
See Cost of non-adoption.
Esthetics:
No significant positive or negative impact.
Discussion:
It would be possible to define an additional level of protocol that
allows multiple classes to contribute to the reconstruction of an
object, combining initialization arguments contributed by each class.
Since a user can easily define that in terms of MAKE-LOAD-FORM without
modifying the Lisp system, it is not being proposed now.
Any type that has a read syntax is likely to appear as a quoted
constant or inside a quoted constant. Pathnames are one example, user
programs often define others. Also many implementations provide a way
to create a compiled-code file full of data (rather than compiled Lisp
programs), and such data probably include extended-type objects.
Moon supports this. David Gray and John Rose made major contributions
to the discussion that produced this improved version 2 proposal.
∂09-Mar-89 1334 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 6
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:34:10 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554064; Thu 9-Mar-89 16:31:08 EST
Date: Thu, 9 Mar 89 16:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue IN-PACKAGE-FUNCTIONALITY, version 6
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu, cl-compiler@sail.stanford.edu
In-Reply-To: <8901310224.AA25846@defun.utah.edu>
Message-ID: <19890309213057.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
IN-PACKAGE-FUNCTIONALITY:NEW-MACRO is fine with me. Typo:
the name of the new macro is misspelled in the example code
in the cost to implementors section.
I don't like the alternate IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
proposal as well.
∂09-Mar-89 1522 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 15:22:22 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554205; Thu 9-Mar-89 18:19:55 EST
Date: Thu, 9 Mar 89 18:19 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19890309192541.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890309181944.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 9 Mar 89 14:25 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
...
I still believe my suggestion would be an improvement, but I think
even better would be
(WITH-CONDITION-RESTARTS signal-form &rest restart-clauses)
where signal-form must be an invocation of SIGNAL, ERROR, WARN, or
perhaps a few others, or a macro that expands into such an invocation.
WITH-CONDITION-RESTARTS must signal an error at all levels of safety if
it does not recognize the signal-form. This is "weird" because it uses
a form for something other than evaluation (but not unprecedented; this
is exactly what SETF does). The advantage is that it just nests with an
existing syntax instead of inventing a new, awkward syntax.
I thought about this. I felt guilty about suggesting it without suggesting
an extension mechanism. However, I agree that practical experience with the
Lispm suggests that the extension mechanism is not really needed. People
nearly always use an explicit call to one of these.
Note that I stole the "good name" WITH-CONDITION-RESTARTS for this
commonly used syntax. The less commonly used primitive that just sets
up the restarts without signalling doesn't need as good a name.
I suppose it woudl be too yucky to consider saying that RESTART-CASE has
this effect when its argument happens to be (or macroexpand into) a call
to ERROR, SIGNAL, etc. huh?
The justification being that these are lexically recognizable as really
associated with the signal.
That would leave the name WITH-CONDITION-RESTARTS available for what
you called ...-INTERNAL, and would eliminate the need for this primitive
as an explicit thing altogether.
Thoughts?
∂09-Mar-89 1527 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 15:27:36 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554211; Thu 9-Mar-89 18:24:42 EST
Date: Thu, 9 Mar 89 18:24 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOS-CONDITIONS (Version 3)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: masinter.pa@Xerox.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
cl-cleanup@sail.stanford.edu
In-Reply-To: <19890309190624.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890309182425.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 9 Mar 89 14:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I favor CLOS-CONDITIONS:YES-OPTION-B, even though it's more
verbose, because it makes for a more consistent language.
I don't think the compatibility issue is important since we're
only talking about being compatible with a prototype that some
people have used, not being compatible with a widely used
standard. Essentially, I agree with JonL's comment of 9 Feb.
Would it make sense to offer only YES-OPTION-B to the whole
X3J13 committee, in order to limit the length of the discussion?
Or is that excessively Fascist?
If no one had been given the opportunity to present an alternative,
it would be too fascist, I think. However, people have had two meetings
worth of time to react and no one has championed the alternate proposal.
My feeling is that option B wins over option A because although it
is syntactically more cumbersome in a few cases, it does away with
the `symbolconcing' feature, which is a real conceptual nightmare,
and because it regularizes the set of rules that people have to learn.
I will flush option A in a proposal to be written tomorrow unless
someone advances cause not to.
∂09-Mar-89 1541 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 6
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 15:40:56 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554242; Thu 9-Mar-89 18:38:22 EST
Date: Thu, 9 Mar 89 18:38 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue IN-PACKAGE-FUNCTIONALITY, version 6
To: sandra%defun@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8901310224.AA25846@defun.utah.edu>
Message-ID: <890309183811.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
I support NEW-MACRO, though would really prefer you change "remove" to
"deprecate". Making this an incompatible change is gratuitous.
In either case, I agree with Moon that removing the SELECT-ONLY
option would eliminate some clutter.
∂09-Mar-89 1539 CL-Compiler-mailer Issue: LOCALLY-TOP-LEVEL (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 15:38:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554236; Thu 9-Mar-89 18:36:20 EST
Date: Thu, 9 Mar 89 18:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOCALLY-TOP-LEVEL (Version 1)
To: CL-Cleanup@sail.stanford.edu
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, CL-Compiler@sail.stanford.edu
In-Reply-To: <8903091815.AA09753@defun.utah.edu>
Message-ID: <19890309233609.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is a cleanup issue, but I'm cc'ing the compiler committee
for their information.
Issue: LOCALLY-TOP-LEVEL
References: None
Related issues: EVAL-WHEN-NON-TOP-LEVEL, DECLARATION-SCOPE
Category: CLARIFICATION / ADDITION
Edit history: Version 1, 9-Mar-89, by Moon
Problem description:
It is desirable to be able to wrap LOCALLY around one or more
top-level forms and have them continue to be treated as top-level
forms. Three examples of how this is useful:
- to put an OPTIMIZE or INLINE declaration into force around
several related forms.
- to put declarations into force around DEFCLASS, or any other
top-level form that lacks a syntax for embedded declarations.
- DECLARATION-SCOPE:LIMITED-HOISTING, which passed in January,
removed the ability to use a DECLARE at the head of the body of a
DEFUN or DEFMACRO to make a declaration that applies to the entire
form, including the lambda-list. We are supposed to use LOCALLY
instead, but forms in the body of LOCALLY are not top-level,
and that changes the semantics of DEFMACRO.
Issue EVAL-WHEN-NON-TOP-LEVEL could not define LOCALLY to treat
its body as top-level forms, because only a special form can do
that and LOCALLY is a macro.
Proposal (LOCALLY-TOP-LEVEL:SPECIAL-FORM):
Change LOCALLY from a macro to a special form, and change the
definition of compiler processing (in EVAL-WHEN-NON-TOP-LEVEL)
so that when a LOCALLY form appears at top level the forms in
its body are processed at top level.
Examples:
(locally (declare (optimize (safety 3) (space 3) (speed 0)))
(defmacro frob (&environment e x y &optional (z (foo x y)))
(mumble x y z e)))
Without this proposal, this would have to be written
(defmacro frob (&environment e x y &optional (z (locally
(declare
(optimize
(safety 3)
(space 3)
(speed 0)))
(foo x y))))
(locally (declare (optimize (safety 3) (space 3) (speed 0)))
(mumble x y z e)))
Rationale:
Wrapping LOCALLY around a form should not change its semantics except
as specified by the declarations, hence the body of a top-level
LOCALLY should be top-level.
A macro cannot have a top-level body unless it expands into a special
form that has a top-level body; otherwise the macro invocation and
the macro expansion would not have identical semantics as top-level
forms. There is no available special form for LOCALLY to macroexpand
into (CLtL doesn't say, but presumably the intent was to expand into
a LET with an empty binding list).
Current practice:
The Zetalisp equivalent of LOCALLY worked to surround top-level forms,
because it was a macro that expanded into COMPILER-LET (stashing the
declarations in a special variable the compiler would look at). This
is of course the wrong way to do declarations, but it shows that the
idea was that you could wrap declarations around a bunch of top-level
forms.
Symbolics Genera 7.4.0 does not implement the proposal (but it does
not implement DECLARATION-SCOPE:LIMITED-HOISTING either). I did
not survey any other implementations.
Cost to Implementors:
A half dozen lines of code in the compiler and a smaller amount
in the interpreter and any program-analyzing programs.
Cost to Users:
None.
Cost of non-adoption:
See the horrible example above.
Performance impact:
None.
Benefits:
More consistent language.
Esthetics:
Improved.
Discussion:
None.
∂09-Mar-89 1635 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Mar 89 16:34:45 PST
Received: by ti.com id AA01060; Thu, 9 Mar 89 18:18:09 CST
Received: from Kelvin by tilde id AA29442; Thu, 9 Mar 89 18:01:54 CST
Message-Id: <2814480087-16198566@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 9 Mar 89 18:01:27 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Cc: pierson <@multimax.encore.com:pierson@mist.encore.com>,
KMP@scrc-stony-brook.arpa, CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
In-Reply-To: Msg of Tue, 7 Mar 89 18:32:46 GMT from Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> Providing no way to modify a readtable's character translation function
> would avoid the problem of people modifying the standard readtable, but
> it would probably also be a nuisance in other situations. My vote would be
> for adding a setf-able function READTABLE-CHARACTER-TRANSLATION as well.
>
> I prefer being able to set things when it's reasonable to do so,
> and I'd like to have the function anyway so that I can call it
> on a readtable and see what its translation function is.
There isn't any point in having both an accessor function and a
COPY-READTABLE option. Since other people want to have the function, I
withdraw my suggestion of modifying COPY-READTABLE.
∂09-Mar-89 1920 CL-Cleanup-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Mar 89 19:19:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 MAR 89 19:14:55 PST
Date: Thu, 9 Mar 89 19:14 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Potential issue: MACRO-SPECIAL-FORMS
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Kent M Pitman
<KMP@STONY-BROOK.SCRC.Symbolics.COM>, cl-compiler@sail.stanford.edu,
cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <19890308022127.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890310031441.0.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
I agree with Moon's position on this.
I have written my own code walker for use in PCL. I keep having to add
special forms to it anyways, and it turns out it is much easier to do
that than deal with screwy "expansions" of "macros".
-------
∂09-Mar-89 2244 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 9 Mar 89 22:44:19 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 280108; Fri 10-Mar-89 01:41:38 EST
Date: Fri, 10 Mar 89 01:42 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890307174023.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890310064205.1.GSB@GANG-GANG.SCRC.Symbolics.COM>
I believe that any change to the status quo is incomplete without
providing a coercion mechanism whose "viewpoint" is that of a sequence.
That is effectively what the current COERCE is, overloaded with those
types which do not conflict with SEQUENCE.
Because of the problem of differing viewpoints, I'm inclined to think
that COERCE should be shrunk down to only being a sequence coercion
function, and all other coercions should be handled by the appropriate
functions.
∂09-Mar-89 2314 CL-Cleanup-mailer Issue EQUALP-GENERIC
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 89 23:14:22 PST
Date: Thu 9 Mar 89 23:11:34-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue EQUALP-GENERIC
To: Moon@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, iim@ECLA.USC.EDU
Message-ID: <12476822243.25.IIM@ECLA.USC.EDU>
> Date: Tue, 7 Mar 89 20:20 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> CLtL says that objects that have components are only EQUALP if the two
> objects are of the same type. Perhaps this vague phrase means that CLASS-OF
> returns the same (EQ) class for both of them. Who enforces this? And who
> enforces that numbers are an exception to this rule? Does every method
> enforce this, or is there some kind of shared code?
Good point. Offhand, I can't think of a good way to share the code via any of
the standard method-combination mechanisms. Semi-minor point: arrays are
another exception to this rule. I say semi-minor, because that means we have
two exceptions, which starts making the rule seem somewhat feeble.
> I couldn't figure out how use-pointer is to be used. Are we saying anything
> about what value a hash table supplies for this argument? Up at the top you
> seemed to imply that hash tables supply T. Then what use is the NIL value?
A NIL argument is intended to allow users to use this function in much the same
way they presently use SXHASH. Since users don't have (portable) access to the
mechanisms by which it is possible to tell whether a hash-code has been
invalidated by some state change in the system, for them to be able to use this
function directly they need to be able to turn off any dependencies on such
state changes.
> The depth thing is a new feature since CLtL p.81 says EQUALP is permitted to
> be non-terminating if given circular arguments.
Yes, but ... I'll have more to say about this at the end of this message.
> The second value is not well enough specified. ... You haven't said anything
> about how to combine the second value. You may be assuming that the second
> value is T or NIL and the appropriate combining function is OR, but you
> haven't said that.
Yes, that is what I intended, and you're right that I should have been more
explicit about it. However ...
> In fact a simple binary flag isn't really good enough, because many
> implementations have multiple levels of memory (volatility, ephemeralness,
> generations) and efficiency dictates that the second value indicate which
> level was depended upon.
Absolutely right. I had even thought about this when I was analysing the
problem. Unfortunately, I forgot about it when I was writing the proposal, and
when I dug out the manuals I have for other Lisp implementations to check my
work against outside sources, none showed up this problem.
> Possibly it would work to require the second value to be an integer and use
> MAX as the combining function. Or perhaps there should be a specific
> combining function for this purpose with an implementation-dependent
> behavior. Even that isn't good enough, because a user who writes an
> equalp-hash method that actually computes a hash code, without recursing into
> components, has to know what to return as the second value. We could say
> that NIL or 0 or some named constant means the first value does not depend on
> any memory locations.
Using MAX isn't right either. Consider an implementation in which memory is
broken up into regions which are collected seperately (no generations, just
smaller regions to be dealt with on any one gc). In such an implementation you
might want to return an integer in which bit positions are associated with
regions, and the appropriate combining function is LOGIOR. So I think it
pretty much has to be an implementation-specific function. A named constant
seems the right way to go for user-computed hash-codes.
> Now wait a minute, I think being independent of the core image and being
> independent of objects changing their address are two different issues.
> There can be other things besides memory addresses that are dynamically
> allocated on a per-core-image basis. Character codes in systems with
> user-defined character registries are a classic example.
Right again. I forgot that things like character codes might change in strange
ways that have nothing to do with memory location. I think use-pointer should
probably mean can't change within the implementation, for compatibility with
SXHASH.
> It's pretty unclear what the EQUALP-HASH method on T would do with a second
> argument of NIL. What else can it use but the pointer (and perhaps the
> class)? I don't see what it can do but return a constant value for all
> objects. Maybe it would be better off signalling an error. Or maybe this is
> another argument against the use-pointer feature.
No, because of the desire to provide functionality similar to SXHASH.
A problem which you didn't comment on (probably because others already have) is
the restriction I included on adding and removing methods. I've pretty much
convinced myself that this could be removed with the addition of a minor amount
of machinery. Specifically, add a function which can be used to determine
whether the definitions of EQUALP or EQUALP-HASH have changed since the last
time you checked. (I'm not going to try to specify it precisely just now.
When I write another version of the proposal, I'll do so then.)
Regarding the depth argument to EQUALP-HASH. I keep waffling on this. My
concern is that if the object to be hashed is circular, and all the methods
that are going to be invoked on the circular parts will continue walking the
circular structure, then EQUALP-HASH will hang. The reason this is potentially
a problem, even though EQUALP is allowed to hang in such circumstances, is that
EQUALP might legitimately be optimized to do an EQL test 'up front'. Thus,
without the depth argument you could potentially try to hash some object and be
unable to, despite the fact that you could find it again if you knew where to
look, because the EQL optimization would pick it up.
Basically, the question is, do the semantics of EQUALP (and EQUAL) include the
idea of doing an EQL test up front or not. If the EQL test is an
'optimization', then it is arguably bogus. However, I suspect that most people
would expect it to be legit, even though the descriptions in CLtL (which don't
say anything it) should hang when comparing any descended circular structure to
itself (and most people would consider the latter behavior rather bizarre).
Needless to say, this situation seems to be bugging me (probably excessively).
On a more general note, I agree with you that finishing this job may be hard,
and may not be possible under the present circumstances. I had two reasons for
going to the trouble.
First, there seemed to me to be a significant number of people who were
interested in seeing such a proposal at least attempted. To paraphrase an
argument that Kent Pitman sometimes uses, better to get a proposal out where
people can actually look at it and judge it on its merits, even if the
consensus ends up being to punt because its too hard or ill-defined a problem,
than to pocket veto. That way we at least have a record that shows that we
gave the problem serious consideration when somebody later complains about what
we've done.
Secondly, I'm really much more interested in the possiblity of specifying how
to do hash-tables with general user-specified test and hash functions. I used
this proposal as a concrete example to think about, and I feel like I'm much
closer to a good solution than I would have been just trying to think about the
problem abstractly. Even if we can't get such a thing into the standard due to
time constraints, if we or anyone else can come up with such a specification
that is widely acceptable, I think a lot of people would be made happier.
So I'll keep working on it, and hopefully you and others will continue to
provide such useful comments. Thanks.
kab
-------
∂10-Mar-89 0916 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Mar 89 09:15:59 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA24750; Fri, 10 Mar 89 10:13:52 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA10642; Fri, 10 Mar 89 10:13:50 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903101713.AA10642@defun.utah.edu>
Date: Fri, 10 Mar 89 10:13:48 MST
Subject: issue IN-PACKAGE-FUNCTIONALITY, version 7
To: cl-cleanup@sail.stanford.edu
Cc: cl-compiler@sail.stanford.edu
Here's a new version of the writeup for this issue. Since Pitman has
indicated he wants to withdraw the SELECT-ONLY proposal, it has gone
away. I also fixed the typo noted by Moon.
Issue: IN-PACKAGE-FUNCTIONALITY
References: IN-PACKAGE (p182-183)
Category: CHANGE
Edit history: 07-Jul-88, Version 1 by Pitman
7-Oct-88, Version 2 by Masinter (discussion)
8-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter
20-Jan-89, Version 5 by Loosemore
30-Jan-89, Version 6 by Loosemore
10-Mar-89, Version 7 by Loosemore
Related-Issues: DEFPACKAGE (passed)
COMPILE-FILE-SYMBOL-HANDLING
Problem Description:
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
A more general problem is that the "Put In Seven Extremely Randoms"
convention described in CLtL is now recognized by many people as being
unsatisfactory for both package definition and package selection.
The DEFPACKAGE macro provides a much cleaner mechanism for package
definition, but there is still a need for a convenient way to select
a package that has well-defined compilation semantics.
Proposal (IN-PACKAGE-FUNCTIONALITY:NEW-MACRO):
Add a new macro:
SELECT-PACKAGE name [macro]
This macro causes *PACKAGE* to be set to the package named NAME,
which must be a symbol or string. An error is signalled if the
package does not already exist. Everything this macro does is also
performed at compile time if the call appears at top-level.
Remove the function IN-PACKAGE from the standard.
Remove the second paragraph of section 11.7 in CLtL. (This includes
the requirement for special compile-time treatment of the various
package functions.)
Rationale:
This could allow improved error checking and modularity, with only
minimal loss of functionality.
The rationale for proposing SELECT-PACKAGE as a replacement for
IN-PACKAGE, rather than simply changing IN-PACKAGE to have this
behavior, is that such an incompatible change would be confusing to
many people, and would make it more difficult to detect obsolete
usages. There is nothing in this proposal that would prevent
implementations from continuing to provide IN-PACKAGE as an extension.
Making SELECT-PACKAGE a macro rather than a function means that there
is no need to require COMPILE-FILE to handle it specially. Since
DEFPACKAGE is also defined to side-effect the compilation environment,
there is no need to require any of the package functions to be treated
specially by the compiler.
The language in section 11.7 of CLtL puts the burden on
implementations of ensuring that all symbols in a file which is
compiled and loaded end up in the same package that they would if the
source file were loaded interpretively. No implementation can
possibly meet this requirement because, in general, the runtime
behavior of the program cannot be predicted by the compiler.
Current Practice:
Probably no one implements this behavior exactly since it's an
incompatible change to CLtL.
Cost to Implementors:
The SELECT-PACKAGE macro can be implemented trivially by using
EVAL-WHEN in its expansion:
(defmacro select-package (name)
`(eval-when (eval compile load)
(setq *package*
(or (find-package ',name)
(error "Package ~s does not exist." ',name)))))
The changes required to COMPILE-FILE to remove the magic treatment
of the package functions are also likely to be small.
Cost to Users:
In most cases, minor syntactic changes to some files would be
necessary. Programmers that are now using the "Put In Seven
Extremely Randoms" convention will probably find it straightforward
to convert their code to do a DEFPACKAGE followed by a
SELECT-PACKAGE.
Cost of Non-Adoption:
The specification of COMPILE-FILE will be much more difficult to
understand.
The standard will require compilers to solve the halting problem.
Benefits:
Modular package declarations would be encouraged and errors due
to demand-creation of packages would be easier to detect.
The specification of COMPILE-FILE will be simplified.
There will be a clear statement of the requirements for program
conformance, as relating to usage of packages.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether
the package should exist already or not) is clearly not aesthetic.
Removing it can't be any worse.
The fact that the currently stated requirements for handling of
the package functions by the compiler are not implementable is
clearly not aesthetic.
Discussion:
The dual use of IN-PACKAGE has not been helpful and is confusing.
Some people may find proposal NEW-MACRO more palatable if it merely
deprecated IN-PACKAGE, instead of removing it entirely.
Loosemore and Moon support proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO.
Pitman says:
I support NEW-MACRO, though would really prefer you change "remove" to
"deprecate". Making this an incompatible change is gratuitous.
-------
∂10-Mar-89 1000 CL-Cleanup-mailer issue IN-PACKAGE-FUNCTIONALITY, version 7
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Mar 89 09:59:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 554628; 10 Mar 89 12:55:40 EST
Date: Fri, 10 Mar 89 12:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue IN-PACKAGE-FUNCTIONALITY, version 7
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu, cl-compiler@sail.stanford.edu
In-Reply-To: <8903101713.AA10642@defun.utah.edu>
Message-ID: <19890310175523.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
IN-PACKAGE-FUNCTIONALITY:NEW-MACRO is okay with me.
∂10-Mar-89 1109 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Mar 89 11:09:41 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554683; Fri 10-Mar-89 14:07:19 EST
Date: Fri, 10 Mar 89 14:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOS-CONDITIONS (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890310140701.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Ok, it's `tomorrow' and no one protested so I did a quick overhaul
of this to remove the dead wood.
I did not deliberately change the content of anything, but it would
help if someone would read it top to bottom for continuity just to
be sure I didn't screw it up. I mainly changed the Rationale and
Discussion, and smoothed some wording here and there where things
got elimiated.
If anyone else wants to add commentary pro or con, they should say
so now.
If no one says anything, I'll assume this is ready to ship.
-kmp
-----
Issue: CLOS-CONDITIONS
References: Condition System (Revision 18)
Category: ADDITION
Edit history: 26-Sep-88, Version 1 by Pitman
06-Oct-88, Version 2 by Pitman
09-Oct-88, Version 3 by Pitman
10-Mar-89, Version 4 by Pitman (remove unsupported options)
Status: For Internal Discussion
Problem Description:
The description of the Common Lisp condition system presupposes
only DEFSTRUCT and not DEFCLASS because it was written when
CLOS had not been adopted. It is stylistically out of step with
CLOS in a few places and places some restrictions which are not
necessary if CLOS can be presupposed.
Proposal (CLOS-CONDITIONS:INTEGRATE):
1. Define that condition types are CLOS classes.
2. Define that condition objects are CLOS instances.
3. Functions such as SIGNAL, which take arguments of class names, are
permitted to take class objects. Such class objects must still be
subclasses of CONDITION.
4. Define that slots in condition objects are normal CLOS slots. Note
that WITH-SLOTS can be used to provide more convenient access to the
slots where slot accessors are undesirable.
5. Incompatibly change the syntax of a slot in DEFINE-CONDITION
to be compatible with a DEFCLASS slot specification.
An implication of this change is that forms like
(DEFINE-CONDITION FOO (BAR) ((A 1) (B 2)))
would have to be written
(DEFINE-CONDITION FOO (BAR)
((A :INITARG :A :READER FOO-A :INITFORM 1)
(B :INITARG :B :READER FOO-B :INITFORM 2)))
6. Permit multiple parent-types to be named in the list of parent types.
Define that these parent types are treated the same as the superior
class list in a CLOS DEFCLASS expression.
7. Eliminate the :CONC-NAME option to DEFINE-CONDITION.
8. Define that condition reporting is mediated through the PRINT-OBJECT
method for the condition type (class) in question, with *PRINT-ESCAPE*
always being NIL. Specifying (:REPORT fn) in the definition of a
condition type C is equivalent to doing
(DEFMETHOD PRINT-OBJECT ((X c) STREAM)
(IF *PRINT-ESCAPE* (CALL-NEXT-METHOD) (fn X STREAM)))
Rationale:
These changes are consistent with the intent of the X3J13 endorsement
of CLOS and the Common Lisp Condition System.
Although items 5 and 7 are incompatible with the interim condition
handling which we've been working with, the overall proposal significantly
improves compatibility with CLOS.
This compatibility will make the language seem less fragmented, and
probably more learnable because there will be fewer paradigms to learn.
Also, items 5 and 7 in particular are an improvement for reasons
unrelated to CLOS if only because they get rid of the need for symbol
concatenation, a process which has been seen to cause problems because
of the transient nature of the binding of *PACKAGE*.
Examples:
Slot specifiers...
A slot specifier of X is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X) is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X V) would no longer be valid.
In addition, other slot specifiers such as
(X :INITARG :EX :TYPE FIXNUM)
are permitted as in DEFCLASS.
Conc names ...
(DEFINE-CONDITION FOOBAR (FOO BAR) (X Y) (:CONC-NAME FUBAR))
would be rewritten
(DEFINE-CONDITION FOOBAR (FOO BAR)
((X :INITARG :X :READER FUBAR-X)
(Y :INITARG :Y :READER FUBAR-Y)))
Report methods ...
(DEFINE-CONDITION OOPS (ERROR) ())
(DEFMETHOD PRINT-OBJECT ((X OOPS) STREAM)
(IF *PRINT-ESCAPE*
(CALL-NEXT-METHOD)
(FORMAT STREAM "Oops! Something went wrong.")))
(ERROR 'OOPS)
>>Error: Oops! Something went wrong.
Current Practice:
Some implementations supporting CLOS probably already do this,
or something very similar.
Cost to Implementors:
If you really have CLOS, this is very straightforward.
Cost to Users:
Small, but tractable.
The main potential problems are:
- :CONC-NAME. There is nothing that keeps an implementation from
continuing to support :CONC-NAME for a short while until old code
has been upgraded.
- The incompatible change to slot syntax. Again, it is possible to
unambiguously recognize a 2-list as old-style syntax and an
implementation can provide interim compatibility support during
a transition period.
Even if implementations did not provide the recommended compatibility
support, users could trivially shadow DEFINE-CONDITION and provide the
support themselves, expanding into the native DEFINE-CONDITION in the
proper syntax.
In any case, the total number of uses of DEFINE-CONDITION at this
point is probably quite small. Searching for them and repairing
each by hand is probably not an expensive operation.
Cost of Non-Adoption:
Conditions will seem harder to manipulate than other user-defined types.
People will wonder if CLOS is really something we're committed to.
Benefits:
A more regular, more learnable language.
Aesthetics:
Improved.
Discussion:
Gregor, Pierson, Moon, and Pitman support this proposal.
People seem to disagree about the status that CLOS might occupy
in the upcoming standard. In spite of a vote of support, they seem
to think it might be optional in some way. Passing this proposal
establishes a clear precedent for the full integration of CLOS into
the emerging language.
The sense of the cleanup committee was that it was acceptable for
a vendor to identify a CLOS-free subset of Common Lisp, but that since
the position of X3J13 seems to be that no resources should be devoted
to work on subsets, it was inappropriate for us to work out the details
of that subset ourselves. Since nothing about this proposal would
impede such a subset, we took that to be adequate basis for presenting
this single proposal.
Moon thinks we might want to add condition types for the errors
CLOS might signal. Richard Mlynarik thinks we should add a generic
function, REPORT-CONDITION, which is used for reporting conditions.
Both of these issues should probably be pursued under separate cover.
∂10-Mar-89 1211 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 10 Mar 89 12:11:33 PST
Received: from fafnir.think.com by Think.COM; Fri, 10 Mar 89 14:41:47 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 10 Mar 89 14:43:13 EST
Received: by verdi.think.com; Fri, 10 Mar 89 14:40:01 EST
Date: Fri, 10 Mar 89 14:40:01 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903101940.AA18605@verdi.think.com>
To: rpg@lucid.com
Cc: Moon@stony-brook.scrc.symbolics.com, dussud@lucid.com,
KMP@stony-brook.scrc.symbolics.com, masinter.pa@xerox.com,
gls@Think.COM, jonl@lucid.com,
jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK,
cl-cleanup@sail.stanford.edu
In-Reply-To: Richard P. Gabriel's message of Thu, 9 Mar 89 12:58:59 PST <8903092058.AA01857@challenger>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
I also agree with ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7) as written by
KMP. I agree with Moon that it is a clarification not a change.
--Guy
∂10-Mar-89 1443 CL-Cleanup-mailer Issue PEEK-CHAR-READ-CHAR-ECHO
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 89 14:43:20 PST
Date: Fri 10 Mar 89 14:41:00-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue PEEK-CHAR-READ-CHAR-ECHO
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12476991441.30.IIM@ECLA.USC.EDU>
Further discussion of this issue here at IIM has lead us to conclude that the
decision made at the Hawaii meeting to accept the proposal
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR was a mistake. Some of the arguments
against it involve flexibility of implementation, but none of us have time to
really do a proper job of writing up those arguments just now. Besides which,
the argument some of us have found most compelling has nothing to do with
implementation flexibility.
The primary argument against the passed proposal is that an effort should be
made to make input appear "where it is used". For example, consider a
read-eval-print loop which prompts with a "* ". Now consider the following
sequence of input characters:
'foo(+ 5 5)
Under the proposal as adopted, if the read-eval-print loop were operating on an
echo stream (which *standard-output* is bound to), then the resulting output
would be
* 'foo(
FOO
* + 5 5)
10
*
Note how the open-paren is misplaced.
Note that the input and output streams of the echo-stream could have been
string-input/output-streams, so this has nothing to do with possible line
oriented, pre-echoed input, as discussed in the proposal. In fact, the whole
discussion of operating system considerations in the proposal is misleading,
since the proposal is describing the behavior of echo-streams, which may have
very little to do with the streams used for direct terminal io, screen
manipulation, and etc.
We wish to have this issue reconsidered.
kab
-------
∂10-Mar-89 1444 CL-Cleanup-mailer Issue STREAM-ACCESS
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 89 14:44:20 PST
Date: Fri 10 Mar 89 14:41:53-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue STREAM-ACCESS
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12476991602.30.IIM@ECLA.USC.EDU>
Proposal STREAM-ACCESS:ADD-TYPES-ACCESSORS, passed at the Hawaii meeting, says
that the types TWO-WAY-STREAM and ECHO-STREAM are mutually exclusive. This
seems inappropriate -- the two seem to be equivelent except that echo-streams
provide the additional echoing functionality.
We wish to add an ammendment to require (or allow, if somebody claims problems
with this) ECHO-STREAM to be a subtype of TWO-WAY-STREAM.
kab
-------
∂10-Mar-89 1445 CL-Cleanup-mailer Issue SUBTYPEP-TOO-VAGUE
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 89 14:44:53 PST
Date: Fri 10 Mar 89 14:42:41-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue SUBTYPEP-TOO-VAGUE
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12476991748.30.IIM@ECLA.USC.EDU>
The proposal SUBTYPEP-TOO-VAGUE:CLARIFY, passed at the Hawaii meeting, says
"SUBTYPEP should signal an error when handed (for either argument) a type
specifier that involves VALUES or the list form of the FUNCTION type."
This prevents a compiler from using such type declarations to do type checking
and such on functional arguments.
We wish to ammend the proposal to strike that paragraph.
kab
-------
∂10-Mar-89 1446 CL-Cleanup-mailer Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER, v1
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 89 14:46:24 PST
Date: Fri 10 Mar 89 14:43:58-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER, v1
To: KMP@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, iim@ECLA.USC.EDU
Message-ID: <12476991984.30.IIM@ECLA.USC.EDU>
Good work Kent. A few comments now, with more to follow once I have time to
really look at this. One thing I'm working on is a function by function
comparison of your list with what we (IIM) currently do.
Many (perhaps almost all) of these could potentially signal STORAGE-CONDITION.
However, as a general rule I don't think we should document that possibility.
ASH: I can't think of any reason for ASH to signal an ARITHMETIC-ERROR.
DECF: might signal SYNTAX-ERROR? Perhaps this should be PROGRAM-ERROR?
GCD: I can't think of any reason for GCD to signal an ARITHMETIC-ERROR.
INCF: might signal SYNTAX-ERROR? Perhaps this should be PROGRAM-ERROR?
LCM: I can't think of any reason for LCM to signal an ARITHMETIC-ERROR.
MOD: the second argument is required, so drop the "is supplied and" from the
DIVISION-BY-ZERO case.
REM: the second argument is required, so drop the "is supplied and" from the
DIVISION-BY-ZERO case.
SCALE-FLOAT: might signal ARITHMETIC-ERROR (fp over/underflow).
The possibility of ARITHMETIC-ERROR being signaled in the following functions
may depend on what kind of error should be associated with operations on fp
NaN's, infinities, and such.
MAX, MIN, SQRT, /=, <, <=, =, >, >=, RATIONAL, RATIONALIZE
Because of CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE, none of MAX, MIN, /=,
<, <=, =, >, and >= will signal fp over/underflow, and reduce to the question
of what ARITHMETIC-ERRORs are signaled by RATIONAL.
kab
-------
∂10-Mar-89 1452 CL-Cleanup-mailer (new) Issue DESCRIBE-UNDERSPECIFIED
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 89 14:52:09 PST
Date: Fri 10 Mar 89 14:49:57-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: (new) Issue DESCRIBE-UNDERSPECIFIED
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12476993072.30.IIM@ECLA.USC.EDU>
I stumbled across this recently when some low-level changes I was making broke
DESCRIBE and I decided to update it to the new spec rather than fixing the old
version.
kab
-----
Forum: Cleanup
Issue: DESCRIBE-UNDERSPECIFIED
References: CLtL p441-2
88-002R, DESCRIBE function
Category: CHANGE, ADDITION
Edit history: Version 1, 10-Mar-89, Kim A. Barrett
Problem description:
The CLOS Specification (X3J13 Document 88-002R) changes the definition of the
function DESCRIBE, making it a generic function. However, it does not specify
any of the protocol needed to make user-defined methods interact properly to
produce some of the effects mentioned in CLtL. For example, CLtL says that
sometimes the method for describing an object will involve describing
something that it finds inside the object, and that such recursive
descriptions are indented appropriately. How do user-written methods achieve
this indentation? Must they arrange for the indentation explicitly, or is
there some automatic mechanism that handles it?
The new specification does not easily lend itself to certain kinds of features
which some implementations have included in their versions of DESCRIBE, such
as analogues to the printer's depth limits (*PRINT-DEPTH*) and circular
structure detection during recursion (*PRINT-CIRCLE*).
In addition, DESCRIBE does not take a stream argument, instead always doing
output to *STANDARD-OUTPUT*. This means that a program which wants to use
DESCRIBE to output some information to a particular stream must rebind
*STANDARD-OUTPUT* around the call to DESCRIBE. This is a nuisance, and is
also potentially a bad idea in implementations which have interrupts and such.
Proposal DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT:
Remove the section of 88-002R which specifies that DESCRIBE is a generic
function. Modify DESCRIBE to accept an optional second stream argument, which
defaults to *STANDARD-OUTPUT*. The value of this argument is the stream which
output will be directed to. Specify that DESCRIBE is implemented in terms of
the generic function DESCRIBE-OBJECT, described below.
DESCRIBE-OBJECT object stream [Generic Function]
The generic function DESCRIBE-OBJECT writes a description of an object to a
stream. The function DESCRIBE-OBJECT is called by the DESCRIBE function; it
should not be called by the user.
Each implementation is required to provide a method on the class
STANDARD-OBJECT and methods on enough other classes so as to ensure that
there is always an applicable method. Implementations are free to add
methods for other classes. Users can write methods for DESCRIBE-OBJECT for
their own classes if they do not wish to inherit an implementation-supplied
method.
ARGUMENTS:
The first argument is any Lisp object. The second argument is a stream; it
cannot be T or NIL.
VALUES:
The values returned by DESCRIBE-OBJECT are unspecified.
REMARKS:
Methods on DESCRIBE-OBJECT may recursively call DESCRIBE. Indentation,
depth limits, and circularity detection are all taken care of automatically,
provided that each method handles exactly one level of structure and calls
DESCRIBE recursively argument if there are more structural levels.
If this rule is not obeyed, the results are undefined.
In some implementations the stream argument passed to a DESCRIBE-OBJECT
method is not the original stream, but is an intermediate stream that
implements parts of DESCRIBE. Methods should therefore not depend on the
identity of this stream.
Rationale:
This proposal was closely modeled on the CLOS description of PRINT-OBJECT,
which was well thought out and provides a great deal of functionality and
implementation freedom. The same implementation techniques applicable to
PRINT-OBJECT will be applicable to DESCRIBE-OBJECT.
The reason for making the return values for DESCRIBE-OBJECT unspecified is to
avoid forcing users to include explicit (VALUES) in all their methods.
DESCRIBE will take care of that.
Current practice:
Probably nobody does precisely what this proposal suggests.
Cost to Implementors:
A fair amount of work may be required, since every method/subfunction of
DESCRIBE in an implementation may need at least some fixing to be in line with
this proposal. On the other hand, that work may already be needed in order to
conform to 88-002R, and this proposal may make the conversion easier by
simplifying the translation of an existing implementation of DESCRIBE.
Cost to Users:
Any users who are using an implementation which supports the current CLOS
specification of DESCRIBE and have defined their own methods will have to
change them. CLOS is sufficiently recent that this probably isn't a big
problem.
Those users who have made use of implementation-specific hooks into DESCRIBE
to define their own methods will likely have to change, but that was already
the case.
Users who are currently binding *STANDARD-OUTPUT* around calls to DESCRIBE may
wish to change their code.
Cost of non-adoption:
Portable DESCRIBE methods may be difficult to write because the protocol they
must follow is insufficiently specified.
Benefits:
The constraints on DESCRIBE methods are better specified, making it easier to
write such methods properly.
Aesthetics:
Minimal.
Discussion:
An additional change which is not included in the present proposal would be to
make the syntax of DESCRIBE and DESCRIBE-OBJECT be
DESCRIBE object &optional stream &key
DESCRIBE-OBJECT object stream &key
allowing implementation-specific extensions to the arguments. A possible
standard keyword argument is :VERBOSE, which might be used to specify how much
output to produce.
It might be desirable to define some new describe control variables analogous
to the printer control variables, ie. *DESCRIBE-LEVEL* and *DESCRIBE-CIRCLE*,
and possibly *DESCRIBE-LENGTH*.
-------
∂10-Mar-89 1511 CL-Cleanup-mailer Issue PEEK-CHAR-READ-CHAR-ECHO
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Mar 89 15:11:34 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554851; Fri 10-Mar-89 18:08:21 EST
Date: Fri, 10 Mar 89 18:08 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue PEEK-CHAR-READ-CHAR-ECHO
To: IIM@ECLA.USC.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <12476991441.30.IIM@ECLA.USC.EDU>
Message-ID: <890310180807.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri 10 Mar 89 14:41:00-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Further discussion of this issue here at IIM has lead us to conclude that the
decision made at the Hawaii meeting to accept the proposal
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR was a mistake.
...
Under the proposal as adopted, if the read-eval-print loop were operating on an
echo stream (which *standard-output* is bound to), then the resulting output
would be ...
* 'foo(
FOO
* + 5 5)
10
*
Note how the open-paren is misplaced. ...
I'm not positive I parsed your example correctly, but let me make a few remarks
that I hope will clarify...
This issue was originally drafted to address interactive streams but was
later revised to address only the result of MAKE-ECHO-STREAM, not an
arbitrary stream with echoing semantics exactly to preclude worry of the
sort you describe -- such as might be the initial value of *STANDARD-OUTPUT*
(or, actually, *STANDARD-INPUT*, I think you mean).
You don't say in your mail whether you champion an alternative or leaving
it vague. If you want to leave it vague, the chief problem is that the -exact-
problem that you seem to be describing comes up in echo from files. The only
way around it is to document which of several techniques you can use to reliably
parse such files to get the echo behavior you want.
In particular, in Macsyma, you can write script files that say:
F(X):=X+1$ /* Definition of F */
G(X):=X+2$ /* Definition of G */
The Macsyma interactive loop prompts with (C1), (C2), etc. before each
input command, and the Macsyma batch file facility wants to be able
to type (Cn) and then echo all the chars of the input expression plus any
up to (but excluding) the start of the next real expression. It wants the
echo to look like:
(C1) F(X):=X+1$ /* Definition of F */
(C2) G(X):=X+2$ /* Definition of G */
but if you don't have this stuff pinned down (so it can peek without echoing)
you end up with:
(C1) F(X):=X+1$ /* Definition of F */
G
(C2) (X):=X+2$ /* Definition of G */
This issue had to be dealt with for such non-interactive cases, and
the adopted technique solves the problem. The adopted technique is not intended
to be read as infringing on the possible implementations for interactive
use for the reasons which I think you're citing -- which others cited as well.
Does this make you feel any better?
∂10-Mar-89 1527 CL-Cleanup-mailer
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 10 Mar 89 15:27:43 PST
Received: from fafnir.think.com by Think.COM; Fri, 10 Mar 89 18:23:55 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 10 Mar 89 18:25:24 EST
Received: by verdi.think.com; Fri, 10 Mar 89 18:22:09 EST
Date: Fri, 10 Mar 89 18:22:09 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903102322.AA20447@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
In going over the votes of January 1989 I have discovered the following
anomalies and propose certain amendments. Larry, should they be written
up as formal proposals, and if so, should they take the form of separate
amendments, or should they consist of new versions of the old issues?
--Guy
(1) SYMBOL-MACROLET-SEMANTICS did not address the question of how
symbol macros interact with *MACROEXPAND-HOOK*. I propose that
expanding a symbol macro should result in calling the hook
function with three arguments, just as for an ordinary macro;
the first argument will be a special system-supplied expansion
function, the second argument the form (a symbol, of course),
and the third the environment. The expansion function, when
called on the other two arguments, will return the expansion.
(2) SYMBOL-MACROLET-SEMANTICS should perhaps also specify that
PSETQ of a symbol-macro symbol behaves like PSETF.
(3) The LOOP Facility has an inconsistency in its examples.
Under the description of WITH it shows the use of AND as
(LOOP WITH binding AND WITH binding AND WITH binding body)
but in the discussion of destructuring an example reads
(LOOP WITH binding AND binding AND binding body)
The formal syntax for WITH prescribes that the word WITH should
*not* be reiterated (but note that the specification of
FOR/AS prescribes that FOR or AS *should* be written again--
possibly mixing them?)
I propose that, for consistency with FOR/AS, the formal syntax
of WITH be changed to require the word WITH to be reiterated,
and that the examples be changed to match.
(4) SUBTYPEP-TOO-VAGUE lists three rules:
* Involving SATISFIES, AND, OR, NOT, MEMBER allows return of NIL NIL,
but no other case does.
* Error if VALUES or FUNCTION involved.
* Must return T T if types EQUAL.
There are cases that fall into more than one of these categories,
and the proposal as approved did not specify a priority ordering
among them.
I happen to agree with the proposal of Kim Barrett to strike the
second point, although simply striking it is not enough. I believe
that the first rule should take precedence over the third.
Therefore I propose that the three points above be condensed
simply to
* Involving SATISFIES, AND, OR, NOT, MEMBER, VALUES. or the list form
of FUNCTION allows return of NIL NIL; no other case may return NIL NIL.
Note that this wording subsumes the third point: if the second value
has to be T, then SUBTYPEP has to get it right, in which case EQUAL
type specifiers will produce T T.
(5) TYPE-OF-UNDERCONSTRAINED has SINGLE-FLOAT and DOUBLE-FLOAT in its
list, but not SHORT-FLOAT or LONG-FLOAT.
I propose to add SHORT-FLOAT, LONG-FLOAT, and RATIONAL to the list.
--Guy
∂10-Mar-89 1529 CL-Cleanup-mailer Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER, v1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Mar 89 15:29:21 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554863; Fri 10-Mar-89 18:26:21 EST
Date: Fri, 10 Mar 89 18:26 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER, v1
To: IIM%ECLA.USC.EDU@AI.AI.MIT.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <12476991984.30.IIM@ECLA.USC.EDU>
Message-ID: <890310182606.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri 10 Mar 89 14:43:58-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Many (perhaps almost all) of these could potentially signal STORAGE-CONDITION.
However, as a general rule I don't think we should document that possibility.
Right. STORAGE-CONDITION is already described as not being an error
exactly because it addresses an implementation failure rather than a
semantic error. I think this distinction is important. I think we should
deal with this by suggesting to Kathy that she mention somewhere that
for this reason, no one should interpret any of the Conditions lists
in the function descriptions as necessarily complete. The whole point
of the condition system is to provide flexibility in this regard. If we
were being exhaustive, we might as well return integer error codes as
the n+1st value.
ASH: I can't think of any reason for ASH to signal an ARITHMETIC-ERROR.
[Heh,heh... Yeah, normally neither could I. I remember in Macsyma I ran
into some implementations where ASH wasn't implemented correctly (due to bugs)
and I had to define it in terms of EXPT for some situations.]
Ok, I'll remove this. It can still signal it of course. We just won't
waste users' time with expecting it.
DECF: might signal SYNTAX-ERROR? Perhaps this should be PROGRAM-ERROR?
Sorry, you're right.
GCD: I can't think of any reason for GCD to signal an ARITHMETIC-ERROR.
Ok.
INCF: might signal SYNTAX-ERROR? Perhaps this should be PROGRAM-ERROR?
Right.
LCM: I can't think of any reason for LCM to signal an ARITHMETIC-ERROR.
Ok.
MOD: the second argument is required, so drop the "is supplied and" from the
DIVISION-BY-ZERO case.
Ok. Around here, we call that a control-Y error.
REM: the second argument is required, so drop the "is supplied and" from the
DIVISION-BY-ZERO case.
Ok.
SCALE-FLOAT: might signal ARITHMETIC-ERROR (fp over/underflow).
Ok.
The possibility of ARITHMETIC-ERROR being signaled in the following functions
may depend on what kind of error should be associated with operations on fp
NaN's, infinities, and such.
NaN were specifically what I was thinking of. The main objection I was worried
about was whether anyone thought that that wasn't the right error (e.g., that
TYPE-ERROR was more appropriate).
MAX, MIN, SQRT, /=, <, <=, =, >, >=, RATIONAL, RATIONALIZE
Because of CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE, none of MAX, MIN, /=,
<, <=, =, >, and >= will signal fp over/underflow, and reduce to the question
of what ARITHMETIC-ERRORs are signaled by RATIONAL.
It's funny I started with numbers because numbers are not really my
strong point. Can you (or someone) please translate this into a
specific suggestion? Thanks.
∂10-Mar-89 1553 CL-Cleanup-mailer (reply to message)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Mar 89 15:53:05 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 MAR 89 15:40:31 PST
Date: 10 Mar 89 15:38 PST
From: masinter.pa@Xerox.COM
Subject: (reply to message)
In-reply-to: Guy Steele <gls@Think.COM>'s message of Fri, 10 Mar 89
18:22:09 EST
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890310-154031-16254@Xerox>
I'd just as soon have them as new versions....
∂10-Mar-89 1553 CL-Cleanup-mailer Re: issue IN-PACKAGE-FUNCTIONALITY, version 7
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Mar 89 15:53:15 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 MAR 89 15:50:29 PST
Date: 10 Mar 89 15:49 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue IN-PACKAGE-FUNCTIONALITY, version 7
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 10 Mar 89 12:55 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
cl-cleanup@sail.stanford.edu, cl-compiler@sail.stanford.edu
Message-ID: <890310-155029-16287@Xerox>
maybe I'm late, but I still liked SELECT-ONLY better than NEW-MACRO. Just
to calibrate, I didn't like removing REQUIRE & PROVIDE, either.
∂10-Mar-89 1723 CL-Cleanup-mailer Re: Issue: CLOS-CONDITIONS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Mar 89 17:23:20 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 MAR 89 17:09:24 PST
Date: Fri, 10 Mar 89 17:09 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: CLOS-CONDITIONS (Version 4)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <890310140701.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890311010901.9.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
One comment is that you should explicitly mention bootstrapping
concerns under cost to implementors. If you just leave it out,
someone may think it is a difficult problem.
-------
∂11-Mar-89 0125 CL-Cleanup-mailer Re: Issue SUBTYPEP-TOO-VAGUE
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Mar 89 01:24:35 PST
Received: by ti.com id AA06075; Fri, 10 Mar 89 18:35:05 CST
Received: from Kelvin by tilde id AA28022; Fri, 10 Mar 89 18:24:41 CST
Message-Id: <2814567840-5079849@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 10 Mar 89 18:24:00 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Kim A. Barrett" <IIM@ECLA.USC.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue SUBTYPEP-TOO-VAGUE
In-Reply-To: Msg of Fri 10 Mar 89 14:42:41-PST from Kim A. Barrett <IIM@ECLA.USC.EDU>
> Date: Fri 10 Mar 89 14:42:41-PST
> From: Kim A. Barrett <IIM@ECLA.USC.EDU>
> Subject: Issue SUBTYPEP-TOO-VAGUE
>
> The proposal SUBTYPEP-TOO-VAGUE:CLARIFY, passed at the Hawaii meeting, says
>
> "SUBTYPEP should signal an error when handed (for either argument) a type
> specifier that involves VALUES or the list form of the FUNCTION type."
>
> This prevents a compiler from using such type declarations to do type checking
> and such on functional arguments.
I don't see any problem here. My compiler has a type testing function
that handles VALUES types itself and converts (FUNCTION ...) to just
FUNCTION before calling SUBTYPEP, so it isn't prevented from doing
anything that it wants to.
If if you want these cases to be permitted, then you will need to define
what they mean.
∂11-Mar-89 1452 CL-Cleanup-mailer amendments to already passed issues
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 89 14:52:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555177; Sat 11-Mar-89 17:50:15 EST
Date: Sat, 11 Mar 89 17:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: amendments to already passed issues
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903102322.AA20447@verdi.think.com>
Message-ID: <19890311225011.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
We should be discussing this under separate headings for
each issue, but in the meantime I couldn't resist offering
my opinions.
Date: Fri, 10 Mar 89 18:22:09 EST
From: Guy Steele <gls@Think.COM>
(1) SYMBOL-MACROLET-SEMANTICS did not address the question of how
symbol macros interact with *MACROEXPAND-HOOK*.
I agree with your proposal.
(2) SYMBOL-MACROLET-SEMANTICS should perhaps also specify that
PSETQ of a symbol-macro symbol behaves like PSETF.
Agreed. This is already implied by the way CLtL describes PSETQ, but
it's better to be explicit so the functionality is not accidentally lost
during editorial work to improve the wording ("x is just like y except"
is not such a great way to write a standard).
(3) The LOOP Facility has an inconsistency in its examples.
Under the description of WITH it shows the use of AND as
(LOOP WITH binding AND WITH binding AND WITH binding body)
but in the discussion of destructuring an example reads
(LOOP WITH binding AND binding AND binding body)
The formal syntax for WITH prescribes that the word WITH should
*not* be reiterated (but note that the specification of
FOR/AS prescribes that FOR or AS *should* be written again--
possibly mixing them?)
I propose that, for consistency with FOR/AS, the formal syntax
of WITH be changed to require the word WITH to be reiterated,
and that the examples be changed to match.
The word should not be reiterated in either case. I think this was
one of the many comments I offered on the LOOP proposal last year,
but apparently it did not sink in.
(4) SUBTYPEP-TOO-VAGUE lists three rules....
This is too complicated for me to offer a knee-jerk opinion.
(5) TYPE-OF-UNDERCONSTRAINED has SINGLE-FLOAT and DOUBLE-FLOAT in its
list, but not SHORT-FLOAT or LONG-FLOAT.
I propose to add SHORT-FLOAT, LONG-FLOAT, and RATIONAL to the list.
I strongly agree.
I'm glad -somebody- is double-checking already passed issues. Also I'm
glad that -you- are.
∂11-Mar-89 1658 Common-Lisp-Object-System-mailer Issue: LOAD-OBJECTS (Version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Mar 89 16:58:32 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01066g; Sat, 11 Mar 89 16:51:27 PST
Received: by challenger id AA05936g; Sat, 11 Mar 89 16:46:51 PST
Date: Sat, 11 Mar 89 16:46:51 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903120046.AA05936@challenger>
To: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu,
Common-Lisp-Object-System@sail.stanford.edu
Subject: Issue: LOAD-OBJECTS (Version 3)
I was a little surprised to see that this proposal talks about load
forms instead of load functions (which goes to show how much I've been
paying attention). After some thought and consultation with Moon, I
realized that part of it was that compiled functions could not be
compiled constants. If we were to allow such constants, I would propose
we consider the alternative of load functions.
The model would be that when objects are being either prepared for
dumping or are being dumped, at certain points the generic function
MAKE-LOAD-FUNCTION would be invoked on objects that needed to be
re-created later. It would return either one or two functions. The
first is a function of 0 arguments that does the initial creation, and
the second is (if present) a function of 1 argument, which is the
initializer. If present it is applied to the created instance. This
simplifies the naming problem in the current proposal, which, while
clever, is a little unpalatable. In particular, it introduces yet
another way to think about variables.
I think people will find the macro approach (the current approach)
baroque, partly because the approach is best understood by thinking of
an input phase to a compiler or some such program, rather than by
thinking about an output phase when everything has already been supposedly
created. For example, when I read the current proposal, I imagined it
in the FASDUMP phase.
One drawback of my proposal is that the function approach is a little
more verbose in some cases. I also think it is subject to more
circularity errors by novices than the macro approach. On the other
hand, the functional approach makes one think about the issues a
little harder when writing the code, which is possibly a good thing.
Here are the examples in the macro proposal:
;; Example 1
(defclass my-class ()
((a :initarg :a :reader my-a)
(b :initarg :b :reader my-b)
(c :accessor my-c)))
(defmethod shared-initialize ((self my-class) ignore &rest ignore)
(unless (slot-boundp self 'c)
(setf (my-c self) (some-computation (my-a self) (my-b self)))))
(defmethod make-load-function ((self my-class))
(let ((name (class-name (class-of self)))
(a (my-a self))
(b (my-b self)))
#'(lambda () (make-instance name :a a :b b))))
Here the computations of NAME, A, and B must be outside the function
#'(lambda ...) so that they get evaluated in the right environment to
avoid a circular (self-referential) structure. For this to work, the
faslout of #'(lambda ...) must also notice any constants or such
things that need similar treatment, which will get NAME, A, and B, if
needed.
;; Example 2
(defclass my-frob ()
((name :initarg :name :reader my-name)))
(defmethod make-load-function ((self my-frob))
(let ((name (my-name self)))
#'(lambda () (find-my-frob name :if-does-not-exist :create))))
Maybe NAME is not something to worry about, but SELF cannot appear in
the #'(lambda ...).
;; Example 3 (expanded to do a hairy thing that cannot be easily done
;; in the macro approach).
(defclass tree-with-parent () ((parent :accessor tree-parent)
(curious-facts :accessor tree-foma)
(children :initarg :children)))
(defmethod make-load-function ((x tree-with-parent))
(let ((class (class-of x))
(children (slot-value x 'children))
(random-info-at-dump-time (compute-random-info x))
(more-random-info-at-creation-time ())
(parent (slot-value x 'parent)))
(flet ((initialize (x)
(setf (tree-foma x)
(combine-info random-info-at-dump-time
random-info-at-creation-time))
(setf (tree-parent x) parent)))
(values
;; creation
#`(lambda ()
(setq more-random-info-at-creation-time
(compute-more-random-info))
(make-instance class :children children))
;; initialization
#'initialize))))
One can imagine the shared lexical environment of the creator and initializer
being a high-bandwidth channel for information, such as the important
information passed in the above example.
Finally, I wouldn't use the name MAKE-LOAD-FUNCTION-USING-SLOTS,
because the structure of the name ...-USING-SLOTS is like
...-USING-CLASS, which is named that way to inform the programmer that
he can discriminate on the metaclass. Maybe,
MAKE-LOAD-FUNCTION-PRESERVING-SLOTS?
-rpg-
∂11-Mar-89 1745 Common-Lisp-Object-System-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Mar 89 17:45:12 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA13023; Sat, 11 Mar 89 18:43:00 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA00878; Sat, 11 Mar 89 18:42:57 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903120142.AA00878@defun.utah.edu>
Date: Sat, 11 Mar 89 18:42:56 MST
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
To: Richard P. Gabriel <rpg@lucid.com>
Cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu,
Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Sat, 11 Mar 89 16:46:51 PST
I haven't been paying too much attention to this issue either -- I've
been trusting Moon to do the right thing on the assumption that he
knew more about it than I did. I think his latest proposal does look
reasonable. However, if there is disagreement about it, I might as
well suggest yet another alternative:
Have two generic functions, not one. The first would get called by
compile-file and it would return a list of components (or whatever)
that are required to reconstruct the object. The compiler would dump
this list of objects in its usual way. The loader would apply the
second generic function to this list to reconstruct the object. It
avoids the nasty syntax you object to, doesn't require functions to be
dumpable, doesn't require any special support for circular constants,
and ought to be real easy to add to the compiler/loader. (You could
essentially convert the constant into a LOAD-TIME-VALUE expression.)
-Sandra
-------
∂11-Mar-89 1938 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 11 Mar 89 19:37:54 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 262224; Sat 11-Mar-89 22:03:27 EST
Date: Sat, 11 Mar 89 22:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890309181944.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890312030341.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 9 Mar 89 18:19 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Thu, 9 Mar 89 14:25 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
...
I still believe my suggestion would be an improvement, but I think
even better would be
(WITH-CONDITION-RESTARTS signal-form &rest restart-clauses)
where signal-form must be an invocation of SIGNAL, ERROR, WARN, or
perhaps a few others, or a macro that expands into such an invocation.
WITH-CONDITION-RESTARTS must signal an error at all levels of safety if
it does not recognize the signal-form. This is "weird" because it uses
a form for something other than evaluation (but not unprecedented; this
is exactly what SETF does). The advantage is that it just nests with an
existing syntax instead of inventing a new, awkward syntax.
I thought about this. I felt guilty about suggesting it without suggesting
an extension mechanism. However, I agree that practical experience with the
Lispm suggests that the extension mechanism is not really needed. People
nearly always use an explicit call to one of these.
Note that I stole the "good name" WITH-CONDITION-RESTARTS for this
commonly used syntax. The less commonly used primitive that just sets
up the restarts without signalling doesn't need as good a name.
I suppose it woudl be too yucky to consider saying that RESTART-CASE has
this effect when its argument happens to be (or macroexpand into) a call
to ERROR, SIGNAL, etc. huh?
The justification being that these are lexically recognizable as really
associated with the signal.
That would leave the name WITH-CONDITION-RESTARTS available for what
you called ...-INTERNAL, and would eliminate the need for this primitive
as an explicit thing altogether.
Thoughts?
Well, it is kind of yucky. On the other hand, it's no yuckier, really,
than my suggestion to make WITH-CONDITION-RESTARTS lexically recognize
these forms, except for one thing: my suggestion means it either lexically
recognizes the form or signals an error. Your suggestion means it either
lexically recognizes the form and attaches the restarts to the condition,
or does not lexically recognize the form and does not attach the restarts
to the condition, but still signals the condition and still establishes
the restarts. The question is, is it a bad thing to signal the condition
with the restarts in effect but not attached to it? Well, maybe it's not
as bad a thing as having another macro just for attaching restarts.
Either way Gabriel is going to say it's baroque and eccentric, and he'll
be right. Right now I'm inclined to agree to modify RESTART-CASE to
specially recognize those signalling forms and attach the restarts to
the condition, but I might change my mind back to the other way.
∂12-Mar-89 1032 Common-Lisp-Object-System-mailer Issue: LOAD-OBJECTS (Version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Mar 89 10:32:40 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01322g; Sun, 12 Mar 89 10:25:36 PST
Received: by challenger id AA06637g; Sun, 12 Mar 89 10:20:59 PST
Date: Sun, 12 Mar 89 10:20:59 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903121820.AA06637@challenger>
To: sandra%defun@cs.utah.edu
Cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu,
Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 11 Mar 89 18:42:56 MST <8903120142.AA00878@defun.utah.edu>
Subject: Issue: LOAD-OBJECTS (Version 3)
Sandra's idea of two generic functions, one producing components and the
other doing construction/further initialization has some merits aside
from the question of dumping functions. I think we should consider it.
-rpg-
∂13-Mar-89 0940 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 4)
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 09:40:01 PST
Received: from JACKIE-O.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 180784; Mon 13-Mar-89 12:33:08 EST
Date: Mon, 13 Mar 89 12:35 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue: CLOS-CONDITIONS (Version 4)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890310140701.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890313173553.9.MLY@JACKIE-O.AI.MIT.EDU>
Date: Fri, 10 Mar 89 14:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Proposal (CLOS-CONDITIONS:INTEGRATE):
1. Define that condition types are CLOS classes.
2. Define that condition objects are CLOS instances.
4. Define that slots in condition objects are normal CLOS slots. Note
that WITH-SLOTS can be used to provide more convenient access to the
slots where slot accessors are undesirable.
This isn't any sort of clarification. The actual clarification required
-- which has been requested several times, and not just by myself -- is
what the *METACLASS* of condition types is.
Condition types may be "CLOS classes" without being STANDARD-CLASSes
Condition objects may be "CLOS instances" without being STANDARD-OBJECTs.
Just what are "normal CLOS slots"? As I see it, the "normalcy" or
otherwise of slots is determined by the metaclass.
My opinion for some time has been that condition types should not be
STANDARD-CLASSes but instead something like READ-ONLY-CLASS.
Conceptually, It Is An Error to modify the slots of condition objects,
which are supposed to be immutable descriptions of part of the state of
a computation. Implementationally,
(setf (slot-value <condition-object> <slot-name>) <new-value>) should
signal an error.
(I also think that conditions in particular have a strong need for
something like :REQUIRED-INIT-KEYWORDS, but that's another story.)
Even if you decide to make condition classes' metaclass STANDARD-CLASS,
the point is that you need to state this, so that users may define
condition classes and mixins using DEFCLASS.
Richard Mlynarik thinks we should add a generic
function, REPORT-CONDITION, which is used for reporting conditions.
Both of these issues should probably be pursued under separate cover.
Since, as you know, I largely regard work on the Common Lisp condition
system as a waste of my time, this won't happen until somebody else
realises that it is needed.
∂13-Mar-89 0946 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Mar 89 09:44:39 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05944; Mon, 13 Mar 89 03:37:17 PST
Message-Id: <8903131137.AA05944@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA05944; Mon, 13 Mar 89 03:37:17 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 13 Mar 89 06:34
To: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: TIME-ZONE-NON-INTEGER
Issue: TIME-ZONE-NON-INTEGER
References: Section 25.4.1 (Time Functions) (p. 443-444)
Category: CLARIFICATION
Edit history: 1-MAR-89, Version 1 by Chapman
Problem Description:
CLtL states that the time zone part of Decoded Time is an integer. However,
it is possible to have a non-integer time-zone.
Proposal (TIME-ZONE-NON-INTEGER:ALLOW)
Specify that the time zone part of Decoded Time is a rational number
(either an integer or a ratio).
Rationale:
For CL to accommodate all possible time designations, it is necessary
to allow time zone to be non-integer.
Some places in the world are on half-hour or quarter-hour times.
Current Practice:
VAX LISP allows time zone to be non-integer.
Adoption Cost:
Shouldn't be too big a change.
Benefits:
See Rationale.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
∂13-Mar-89 1009 CL-Cleanup-mailer Issue: CLOS-CONDITIONS (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 10:09:13 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555769; Mon 13-Mar-89 13:06:17 EST
Date: Mon, 13 Mar 89 13:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOS-CONDITIONS (Version 4)
To: Mly@AI.AI.MIT.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19890313173553.9.MLY@JACKIE-O.AI.MIT.EDU>
Message-ID: <890313130600.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Mon, 13 Mar 89 12:35 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Date: Fri, 10 Mar 89 14:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Proposal (CLOS-CONDITIONS:INTEGRATE):
1. Define that condition types are CLOS classes.
2. Define that condition objects are CLOS instances.
4. Define that slots in condition objects are normal CLOS slots. Note
that WITH-SLOTS can be used to provide more convenient access to the
slots where slot accessors are undesirable.
This isn't any sort of clarification. The actual clarification required
-- which has been requested several times, and not just by myself -- is
what the *METACLASS* of condition types is.
I do not agree that it is a -necessary- thing to specify the Meta-Class
of conditions because all intended uses of conditions can be done
without this information.
I agree that it is a -possibly useful- thing to do, but there is a down
side to it -- it would unnecessarily tie the hands of people who want
implementation flexibility for one reason or another.
I happen to like your idea of a READ-ONLY-CLASS, by the way.
I do not mind if someone proposes this change, but I do believe it is not
properly a part of the "essential changes" to integrate conditions with
CLOS. As such, I would prefer that it not be raised as part of this issue
because I don't want to risk this level of changes not going through due
to worry over that issue.
I would be happy to see you write up a separate proposal on the issue.
I can't guarantee that it will be accepted due to all the impending
deadlines, but my vote will not be to table it on mere procedural grounds.
I can't speak for anyone else.
Please call the new issue CONDITION-META-CLASS.